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C\1  CO  CD 


1.0  Introduction 


This  document  is  the  Final  Report  under  Air  Force  Research  Laboratory  (AFRL)  contract  number 
F30602-99-C-0214,  performed  by  Giordano  Automation  Corp.,  entitled  Application  of 
Model-Based  Reasoning  Tools  Used  to  Enhance  and  Improve  Diagnostic  Performance  to 
Improve  Air  Force  Maintenance. 

Under  the  contract,  initiatives  were  conducted  to  improve  the  sustainment  and  modernization  of 
the  Turbine  Engine  Monitoring  System  (TEMS).  TEMS  is  deployed  on  the  A-10  and  KC-135 
aircraft  to  monitor  engine  parameters  and  provide  alerts  to  the  ground  crew  upon  the  occurrence 
of  Malfunction  Transactions  (MALTRAN).  The  TEMS  system  was  designed  around  1970’s 
technology,  and  has  numerous  sustainment  issues  because  of  aging  and  diminishing 
manufacturing  source  (DMS)  issues. 

This  program  was  conducted  under  a  Program  Research  and  Development  Authority  (PRD A) 
effort.  The  efforts  represent  a  tme  partnership  between  the  two  sides  of  the  Air  Force  that  rarely 
communicate:  the  R&D  side  represented  by  AFRL,  and  the  post-deployment  sustainment 
organization,  WR-ALC.  The  partnership  focused  on  introducing  new  technologies  and  innovative 
solutions  to  sustainment,  and  at  the  same  time,  provided  clear  insight  to  the  R&D  community  the 
logistic  impacts  of  early  design  decisions. 

This  Final  Report  details  the  various  initiatives  performed  as  well  as  the  overall  results  of  each 
initiative.  The  report  attempts  to  describe  these  initiatives  with  a  broad  brush.  Additional  details 
on  the  specific  efforts  may  be  found  in  individual  reports  that  have  been  prepared  and  delivered 
during  the  contract  period. 

1.1  Sustainment  Projects 

o  TEMS  SRU  TPS  Re-Engineering 
o  FFSCU  Re-Engineering 
o  TEMS  EPU  Anomaly  Detection  &  Correction 
o  FFSCU  TPS 
o  WinDDU  Software  Port 
o  Processor  Card  TPS  Development 

1.2  Modernization  Projects 

o  TEMS  COTS  Replacement  Market  Survey 
o  TEMS  COTS  Replacement  Weapon  System  Survey 
o  UDAS  Specification 
o  UDAS  RFI  &  RFP 

o  UDAS  Prototype  Development,  Test  &  Validation 
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2.o  Sustainment  Projects 

2.1  TEMS  SRU  TPS  Re-Engineering 

The  major  objective  of  this  effort  was  to  provide  enhancements  to  the  maintenance  of  the 
A-10/KC-135  Turbine  Engine  Monitoring  System  (TEMS)  through  implementing  the 
Diagnostician  model-based  reasoning  tool  in  a  selection  of  Shop  Replaceable  Units  (SRU)  level 
test  program  sets.  This  effort  included  re-engineering  of  the  TEMS  SRU  level  test  programs  to 
improve  run-time  efficiency,  accuracy  and  vertical  testability. 

The  Turbine  Engine  Monitoring  System  (TEMS)  performs  parametric  analysis  of  KC-135 
and  A- 10  engine  data.  The  TEMS  unit  is  mounted  on  the  aircraft.  The  TEMS  LRU  and  SRU  level 
testing  is  performed  at  the  Warner  Robins  Air  Logistics  Center  WRALC  in  Georgia  (previously 
at  Kelly  AFB  in  San  Antonio).  Since  the  SRU  and  LRU  level  test  resources  are  co-located  at  the 
same  facility,  a  rare  opportunity  exists  to  analyze  the  level  of  test  result  consistency  across  the 
two  testers. 

In  the  past  few  years,  the  TEMS  SRU  level-testing  software  was  re-hosted  from  a  VAX 
controller  to  a  PC  controller.  At  that  time,  significant  inefficiencies  in  the  structure  and 
documentation  of  the  test  programs  were  identified.  Inconsistencies  were  also  identified  between 
the  LRU  and  SRU  level  tests.  A  proof-of-concept  demonstration  was  conducted  in  which  it  was 
determined  that  by  applying  reasoning  tools  to  the  test  programs,  that  the  run-time  speed  and  test 
program  accuracy  were  significantly  enhanced.  At  the  same  time,  the  structured,  engineering 
process  required  to  implement  the  Diagnostician  resulted  in  identification  of  specific  problem 
areas,  which  could  then  be  resolved.  The  proof-of-concept  demonstration  was  performed  on 
091350-RPM  Fuel  Flow  Conditioner  circuit  card.  Table  1  below  shows  the  results  of  the 
demonstration. 


Table  1  -  Diagnostician  Benefits  to  TEMS  SRU  TPS 
Demonstration  done  on  091350  TEMS  A6  Card 


Run  # 

Fault  Inserted 

Original 

Time 

Diagnostician 

Time 

Time 

Saved 

% 

Faster 

Original 

Callout 

Diagnostician 

Callout 

Run  1 

Go-chain 

00:23:51 

00:15:03 

00:08:48 

36.9% 

Pass 

Pass 

Run  2 

U5.3  SAO 

00:22:57 

00:06:53 

00:16:04 

70.0% 

U5,U13,U27, 

U12 

U5,U2,U13,U27 

Jumper 

Run  3 

U8.ll  SAO 

00:13:48 

00:05:17 

00:08:31 

61.7% 

AR2,C2,R3,R4 

U8,R7,R8 

Run  4 

U7.13  SAO 

00:23:11 

00:04:26 

00:18:45 

80.9% 

AR2,C2,R3,R4 

U7 

Run  5 

U28.4  SAO 

00:18:45 

00:06:23 

00:12:22 

65.9% 

U16,U17,U18,U 

19,U20,U21,U28 

U16,U17,U18,U 

19U20,U21,U28 

Run  6 

AR1.10  SAO 

00:16:20 

00:04:55 

00:11:25 

69.9% 

AR1,R1,R2 

AR1,  Rl,  R2 

Run  7 

U7.ll  SAO 

00:15:30 

00:06:07 

00:09:23 

60.5% 

AR2,C2,R3,R4 

U7,R7,R8 

Run  8 

AR1.3  SAO 

00:16:04 

00:06:53 

00:09:11 

57.2% 

AR1,R1,R2 

AR1,  R1,R2 

Run  9 

U12.2  SAO 

00:20:41 

00:08:02 

00:12:39 

61.2% 

U12,U3,U16 

U12,U3,U16 

The  demonstration  also  determined  that  the  commonality  of  test  results  between  the  SRU 
and  LRU  level  tests  could  be  increased  and  the  mechanism  could  be  put  in  place  to  upgrade  the 
re-engineered  test  programs  based  on  test  results  and  correlation  over  time  and  history. 


2 


Many  of  the  various  TPS  improvements  came  from  the  run-time  characteristics  of  the 
reasoning  tools  as  well  as  the  application  of  a  structured  engineering  process  for  development  of  a 
proper  diagnostic  knowledge  base  for  use  with  the  Diagnostician.  The  result  of  re-engineering 
the  TPSs  on  the  rest  of  the  TEMS  cards  as  part  of  this  project  likewise  verified  the  significant 
improvement  in  TPS  quality  in  terms  of  both  the  Go-chain  and  the  Diagnostic  process. 

The  efforts  described  in  this  Final  Report  were  based  upon  a  contract  to  apply  the 
Diagnostician  and  the  engineering  analysis  across  all  of  the  TEMS  Electronic  Processing  Unit 
(EPU)  circuit  cards.  The  automatic  diagnostic  reasoning  approach  that  Giordano  Automation 
used  in  re-engineering  the  test  program  sets  has  been  accomplished  using  a  set  of  tools  developed 
by  Giordano  Automation.  The  run-time  tool,  Diagnostician,  provides  automated  diagnostics  that 
is  integrated  into  the  Test  Program.  The  development  tool,  Diagnostic  Profiler,  was  used  to  create 
the  Diagnostic  models. 

2.1.1  SUMMARY  OF  PROJECT  RESULTS 

The  complexity  of  the  TEMS  TPS  code  has  been  significantly  simplified  by  inserting  the 
Diagnostician.  The  traditional  troubleshooting  trees  that  were  previously  implemented  with 
several,  hard  to  maintain  GOTO  statements,  were  replaced  with  a  simple  conversation  loop  with 
the  Diagnostician.  By  eliminating  this  complex  diagnostic  hard-coded  logic,  the  resulting  TPSs 
are  vastly  easier  to  maintain.  Also,  transporting  the  modified  TPSs  and  the  Diagnostician  to  an 
alternate  test  resource  is  much  more  straightforward.  This  approach  has  also  allowed  for  a 
significant  reduction  in  the  number  of  lines  of  code  for  each  Test  Program  as  is  shown  in  Table  2. 


Table  2  -  TPS  Project  Completion  Summary 


TPS 

Old  TPS 
#  Lines 

New 

TPS# 

Lines 

#  Old 
Probes 

#  New 
Probes 

Go-To's 

Removed 

Modifications  Compared 
to  old  code 

091150 

16,468 

10,770 

58 

18 

162 

Significantly  reduced  #  of  probes 
and  code  lines 

091200 

9,715 

9,300 

76 

10 

221 

Significantly  reduced  #  of  probes 

R1  test  was  added 

091250 

10,524 

7,492 

51 

10 

219 

Significantly  reduced  #  of  probes 

091300 

4,521 

6,482 

41 

28 

51 

-  WB  Diag  test  added  to  Go-chain  to 
reduce  ambiguity 

-  Runs  R76  &  R4  first  to  reduce 
ambiguity 

-  WB,  NB  &  VIBCLK  tests  results 
are  displayed  in  log  files  as  applied 

-  Tolerances  were  tightened 
accordingly 

091350 

28,524 

11,532 

117 

50 

1401 

Reduced  #  of  probes 

091450 

Combined 

w/ 

091460 

Combined 

w/ 

091460 

-  Combined  091450  &  091460 

TPS’s  to  one  linked  ATLAS 
program 

091460 

16,553 

24,551 

57 

29 

732 

Added  a  calibration  test  to  the 
potentiometer  on  the  4.9  Volt 
Reference  Test. 

9383755 

N/A 

12,436 

N/A 

28 

N/A 

New  Program. 

091600 

78,589 

14,099 

113 

72 

1422 

Combined  all  4  old  mod  code  into  1 
linked  TPS  program 

091650 

55,493 

8,851 

69 

30 

1804 

Combined  all  6  modules  into  1 
linked  program 

091750 

19,977 

- 

86 

- 

- 
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The  overall  test  results  have  been  significant  in  that  we  see  a  vast  improvement  in  the 
overall  diagnostics,  a  reduction  in  the  amount  of  probes  in  general  on  each  individual  board,  and 
the  re-orientation  and  modular  structuring  of  the  test  program  to  allow  it  to  be  easily  migrated  to 
another  functional  test  system.  In  addition,  the  Diagnostic  Profiler  can  be  applied  directly  to 
those  comparable  tests  on  any  migrated  test  system  to  allow  capturing  of  the  diagnostic  data  as 
you  migrate  from  one  tester  to  the  other.  This  would  be  a  significant  reduction  in  overall  test 
program  costs  in  migration  of  the  test  programs  to  alternate  functional  test  system.  All 
appropriate  Software  Delivery  Forms  for  the  various  assemblies  test  programs  that  have  been 
certified  through  the  LYSTA  organization  of  the  Warner  Robins  Air  Logistic  Center  (WRALC) 
Software  Development  department  were  transmitted  to  the  TEMS  Equipment  Specialist  for 
displacement  and  disposition  for  use  on  the  MATE  390  Test  System. 

In  general  the  test  programs  have  been  dramatically  improved  on  the  go  chain  to  increase 
accuracy  where  correlation  problems  have  existed  between  the  LRU  and  the  SRU  test  system.  A 
major  improvement  was  to  modularly  separate  the  various  test  program  sub-sections  into  modular 
stand-alone  tests,  which  can  be  easily  maintained,  de -bugged  and  transported.  In  addition,  all 
documentation  and  supporting  information  is  provided  to  the  Air  Force  as  part  of  this  contract  in 
order  to  allow  total  organic  maintenance  and  support  of  these  Test  Programs  in  the  future.  Due  to 
the  use  of  the  Diagnostician,  a  more  accurate  and  efficient  resolution  to  the  specific  component 
failure  is  realized  with  the  upgraded  diagnostics.  The  diagnostic  process  for  the  boards  all  exhibit 
a  reduction  of  the  number  of  probes  from  the  previous  test  programs  in  order  to  accomplish  an 
improved  diagnostic  environment.  In  addition,  the  more  complicated  "fault  tree”  approach  to 
diagnostics  has  been  eliminated.  In  effect,  a  model  has  replaced  the  manual  fault  tree  depiction  of 
the  individual  probe  processes.  The  diagnostic  model  is  much  easier  to  maintain  and  upgrade  and 
support  as  any  discrepancies  or  anomalies  occur.  A  major  benefit  is  that  the  diagnostic  process 
through  the  Diagnostician  allows  a  direct  application  and  migration  to  a  migrated  test  program  on 
another  Test  platform  as  the  MATE  390  is  phased  out  in  the  future. 


4 


2.2  FFSCU  Re-Engineering 

The  Fuel  Flow  Signal  Conditioning  Unit  (FFSCU)  is  an  airborne  LRU  that  reads  fuel 
flow  data  and  provides  a  corresponding  input  to  the  TEMS  EPU.  The  TEMS  FFSCU  has  become 
a  critical  sustainment  issue  for  TEMS.  The  FFSCU  was  originally  designed  in  the  1970s.  Since 
its  inception  it  has  been  proprietary  to  the  OEM.  The  government  has  no  knowledge  of  the 
electronic  circuitry  of  the  FFSCU  or  the  input  signal  profile  and  has  been  unable  to  develop 
organic  test  or  repair  capability  for  the  unit.  The  OEM  is  the  sole  repair  and  manufacturing 
source.  Repair  costs  escalated  to  $10,000  each  in  1997.  The  OEM  has  been  increasingly 
unresponsive  to  Government  requirements  for  repair  of  units.  This  is  primarily  due  to  the  age  of 
the  item  and  relatively  low  demand  rate  on  the  part  of  the  Air  Force.  As  a  result,  several  years 
ago,  the  OEM  had  raised  the  cost  of  repair  of  FFSCU  units  to  approximately  10K  per  unit. 

Due  to  these  problems  with  repair  of  the  FFSCU,  and  the  fact  that  the  requirement  had  become 
critical  to  A- 10  operations  (as  a  MICAP  reportable  item),  the  TEMS  System  Manager  decided  to 
look  for  an  alternate  source  for  FFSCU  spares  and  support.  They  located  Apex  Signal,  a  company 
with  extensive  experience  with  FFSCU  requirements.  The  APEX  engineers  discovered  that  the 
original  design  contained  a  potted  brick  that  was  not  field  repairable  and  was  no  longer  available 
as  a  standard  product  because  it  contained  many  obsolete  components. 

The  TEMS  System  Manager  initiated  a  project  to  re-engineer  the  FFSCU  by  a  new  manufacturer, 
and,  at  the  same  time,  provide  the  organic  AF  depot  with  the  capability  to  test  the  FFSCU. 

The  original  intention  was  to  re-engineer  a  FFSCU  to  the  exact  specifications  of  the  original 
FFSCU.  Subsequent  discussions  with  the  A- 10  System  Program  Director  (SPD)  resulted  in  the  A- 
10  requirements  for  a  FFSCU  that  complies  with  an  updated  set  of  specifications  for  the  A- 10 
aircraft.  A  new  specification  was  developed,  and  the  vendor  is  currently  in  the  process  of 
performing  independent  laboratory  tests  for  acceptance  of  the  FFSCU.  When  these  tests  are 
successfully  completed,  flight  tests  and  flight  qualification  will  be  initiated  with  the  A- 10  SPD. 

A  contract  was  put  in  place  to  accomplish  the  following: 

1 .  Update  the  design  with  new  components  to  eliminate  the  obsolete  components 

2.  Repair  a  total  of  29  units  by  either  salvaging  good  modules  from  returned  units  or 
replacing  failed  modules  with  the  revised  layout. 

3.  Generate  a  functional  test  process  and  associated  hardware/software  to  accomplish 
this  testing  as  an  organic  Air  Force  process. 

4.  Provide  design  documentation  (schematics)  at  a  level  necessary  to  allow  for  organic 
AF  functional  testing. 

This  was  subcontracted  as  a  low-cost  effort  (130K),  not  a  major  re-design  program.  The  goal  was 
to  get  units  out  in  the  field  to  support  operations  quickly  and  efficiently. 

The  only  environmental  requirements  placed  in  the  statement  of  work  were  that  “Any  newly 
designed  circuit  elements  shall  meet  the  following  environmental  specifications:  Withstand 
altitude  excursions  from  -250  to  +70,000  feet,  and  Withstand  temperature  excursions  from  -65  F 
to +165  F.” 

The  A- 10  SPD  understood  this  to  be  a  new  design  of  the  FFSCU,  and  therefore,  sought  to  place 
full,  updated  and  modern  environmental  testing  on  the  unit.  These  requirements  were  above  and 
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beyond  the  original  FFSCU  specifications,  and  required  more  extensive  design  work  and 
extensive  environmental  testing  be  accomplished  by  APEX,  which  were  beyond  the  scope  of  the 
original  subcontract. 

It  is  important  to  point  out  that  the  FFSCU  is  failing  due  to  typical  aging  problems,  not  due  to 
environmental  stresses  on  the  unit.  Further,  it  is  important  to  note  that  the  FFSCU  is  totally 
passive  in  the  A- 10.  It  does  not  interface  with  the  fuel  lines. 

Based  on  A- 10  updated  requirements  for  environmental  characteristics  of  all  items  being  put  on 
the  aircraft,  the  initial  effort  was  stopped  by  the  TEMS  Program  Manager.  The  program  was  re¬ 
initiated  as  a  FFSCU  re-design  effort  to  satisfy  A- 10  environmental  requirements  under  a  separate 
contract. 

Under  that  effort,  Giordano  Automation  worked  with  the  A- 10  SPD  to  identify  updated 
environmental  requirements,  and  prepared  an  updated  FFSCU  requirements  specification,  which 
was  coordinated  through  the  TEMS  office  and  the  A- 10  SPD.  A  new  effort  was  initiated  with 
APEX  based  on  the  updated  specification. 

The  plan  is  to  test  the  updated  design  through  an  independent  laboratory,  and  then  conduct  flight- 
testing.  Subsequently,  under  a  separate  contract  effort,  a  test  program  set  for  depot  testing  was 
prepared  on  the  APST  test  system  in  Warner  Robins  and  has  been  sold  off  for  use  in  Depot 
testing  of  the  FFSCU. 

Once  APEX  completes  the  Environmental  and  EMI  testing  through  an  independent  test  lab,  the 
A- 10  SPD  and  Giordano  Automation  will  coordinate  flight-testing  and  certification  of  the  FFSCU 
units  repaired  under  the  new  repair  process  and  source. 
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2.3  TEMS  EPU  Anomaly  Detection  &  Correction 

The  A- 10  aircraft  was  experiencing  high  rates  of  a  vibration  fault  call-out  (MALTRAN 
Event)  in  the  field  that  could  not  be  duplicated  in  the  depot.  In  this  false  call-out,  the  EPU  reports 
excessive  vibration,  ranging  from  30  to  250  mils,  and  the  aircrew  reports  no  occurrence  of 
excessive  vibration.  The  upper  tolerance  limit  for  vibration  is  4  mils.  Since  this  failure  requires  a 
maintenance  action  before  the  aircraft  can  be  returned  to  flight  operations,  the  ground  crew  would 
replace  the  EPU  to  resolve  the  failure  and  turnaround  the  aircraft.  This  situation  resulted  in  a  high 
level  of  Cannot  Duplicate  (CND)  rates  for  the  TEMS  EPU.  At  the  depot,  no  failures  could  be 
found  on  these  EPUs. 

Giordano  Automation  was  tasked  to  investigate  the  problem,  and  develop  and  document  a  process 
for  the  detection  of  this  problem  in  the  EPU  depot,  and  the  subsequent  repair,  or  correction  of  this 
problem.  In  support  of  this  task,  Giordano  Automation  subcontracted  with  the  EPU  OEM, 
Northrop  Grumman  Corporation. 

The  investigation  revealed  that  this  A- 10  TEMS  Vibration  Event  is  caused  by  the  EPU  corrupting 
the  digitized  vibration  signal.  The  corruption  is  caused  by  growth,  on  the  EPU  motherboard  and 
enclosure,  of  a  foreign  substance,  which  contains  sulfur  (likely  residue  from  firing  of  the  cannon 
on  the  A- 10).  The  accumulation  of  this  growth,  exacerbated  by  high  amounts  of  moisture 
intrusion  into  the  enclosure,  causes  a  shorting  out  of  components  under  certain  flight 
circumstances. 

The  investigation  further  resulted  in  finding  that  the  current  depot  test  processes  at  the  LRU  level 
were  not  comprehensive  enough  to  uncover  these  problems.  A  more  comprehensive  test  and 
inspection  process  has  been  defined  and  documented.  Properly  implemented,  these  processes 
should  significantly  decrease  this  nuisance  situation  for  A- 10  flight  and  ground  crew  and  the 
cycling  of  TEMS  units  through  repair  cycles. 

2.3.1  DETAILED  EFFORTS 

Because  of  the  high  rates  of  the  vibration  anomaly  in  the  field,  user  groups  noted  the  repeat 
problem  units  and  began  tracking  by  serial  number.  Tracking  by  S/N  is  not  always  done  in  the 
repair  process.  Units  were  cycled  through  the  repair  facilities  with  no  detected  problems  and 
were  recycled  as  serviceable.  Once  the  depot  determined  the  problem  was  remaining  with  certain 
EPUs,  these  EPUs  were  taken  out  of  the  repair  cycle.  These  EPUs  were  used  in  the  investigations 
performed. 

The  EPUs  with  known  serial  numbers  that  exhibited  the  problem  were  cycled  through  an 
extensive  test  process  at  Northrup  Grumman  Group  (NGC)  which  included  testing  at  a  variety  of 
environmental  excursions.  The  units  were  then  followed  to  a  user  destination  where  their  flight 
operation  was  closely  monitored. 

A  variable  that  greatly  influences  this  investigation  and  has  much  to  do  with  data  collection  in 
general  in  the  A- 10  EPU,  is  the  environmental  location  of  the  unit  and  the  fact  that  it  is  not 
sealed.  Extensive  moisture  collects  in  the  compartment,  rack  mounting,  and  cable  connector 
shells  in  the  A- 10  aircraft.  There  is  a  vent  to  the  compartment  that  allows  driven  rain  to  enter. 
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NGC  determined  that  a  corrosion  is  formed  on  the  underside  of  the  “motherboard”  which  is 
located  next  to  the  inside  base  of  the  EPU.  The  mother  board  is  the  printed  circuit  module  that 
holds  the  13  electronic  circuit  card  edge  connectors  (CCAs)  in  the  EPU  and  distributes  all  the 
interconnects  between  these  CCAs  and  the  outside  connectors.  The  corrosion  is  forming,  over 
time,  on  the  motherboard,  at  a  location  directly  over  one  of  the  drain  holes  located  in  the  bottom 
of  the  EPU  housing.  Although  all  of  the  printed  circuit  modules  in  the  EPU  are  “conformal 
coated”,  but,  in  time,  the  corrosion  wins.  The  troublesome  area  is  not  visible  unless  the 
motherboard  is  removed;  an  extensive  inspection  process  not  normally  conducted  during  depot 
repair.  The  process  of  removing  the  motherboard,  inspecting  it  and  cleaning  it,  and  re-coating  has 
been  added  to  the  depot  repair  process. 

Further,  the  problem  can  only  be  detected  in  the  repair  facility  only  during  temperature  excursion 
testing.  The  low-end  temperature  specification  is  -54  degrees  C.  NGC  found  that  none  of  the 
units  would  pass  tests  below  a  temperature  below  -45  degrees  C.  It  was  recommended  that  the 
repair  facility  test  process  will  be  amended  to  operate  the  EPU  under  test  at  the  -45  degree  C  to 
detect  the  vibration  anomaly. 

A  further  part  recommendation  was  to  seal  the  two  drain  openings  directly  beneath  the  corrosive 
area  forming  on  the  motherboard.  There  will  still  remain  4  drain  holes  in  the  bottom  of  the  EPU 
housing. 

A  side  point;  conformal  coating  will  not  seal  the  junction  where  the  CCA  edge  connector  plugs 
into  its  mating  counterpart  on  the  motherboard.  This  condition  exists  in  all  electronic  devices.  If 
enough  moisture  collects  inside  the  housing,  it  will  accumulate  in  those  many  junctions  where  the 
pins  mate  to  sockets.  A  sealed  pin-to-socket  connection  is  almost  impossible  unless  the  whole 
unit  is  sealed  and  pressurized.  Any  plans  to  re-engineer  the  EPU  should  include  that  feature. 

Another  recommendation  is  that  A- 10  SPD  aircraft  manager  assistance  is  required  in  the  matter  of 
correcting  the  problem  of  exposure  to  excessive  moisture. 

It  was  recommended  that  further  investigation  should  also  be  performed  to  determine  if  the 
TEMS  EPU  housing/chassis  is  involved  in  the  ground  return  of  the  complete  system.  If  the 
aircraft  28  Vdc  power  system  relies  on  the  aircraft  chassis  as  a  ground  return  circuit,  and  the  same 
applies  to  some  or  all  of  the  sensor  signal  cabling,  it  is  imperative  that  the  physical  connections 
between  EPU  chassis  and  aircraft  are  corrosion  free.  Corrosion  does  exist  at  these  junctions.  The 
socket/pin  connections  between  the  EPU  chassis  and  aircraft  mounting  rack  can  and  do  become 
excessively  corroded  in  the  A- 10.  Sensor  signal  corruption  in  aircraft  can  be  traced  to  this 
condition.  To  save  a  great  deal  of  weight  in  aircraft,  it  may  be  that  one  copper  conduction  wire 
was  used  throughout  rather  than  including  a  second  as  a  signal  return  path.  If  the  aircraft  chassis 
is  involved  in  ground  returns,  “ground  loops”  can  exist  which  cause  many  problems  in  the 
discipline  of  data  acquisition. 

A  report  documenting  the  findings  and  the  test  process  was  prepared  and  delivered. 

The  figure  below  identifies  the  test  and  field  investigation  cycles  for  each  EPU,  by  serial  number, 
that  was  cycled  through  the  investigative  process. 
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Table  3  -  EPUs  and  Field  Investigation  Results 


Part  Number 

9058027-1 OROR 

S/N 

020008 

Shop  Order 

W083215 

Present  loc. 

In  Aircraft 

Date 

7/26/2000 

9/11/2000 

9/11/2000 

9/18/2000 

11/14/2000 

11/22/2000 

Failure 

Vib  reading  of  34.0  sb 
<.5 

Vib  readings  of  0.6  sb 
<0.5 

No  Power 

No  Failures  Unit 

Passes  all  Tests 

Action 

Clean  Mother  Board 

Swap  091300-302 

S/N  0200165  with  S/N 
0290104  from  EPU 

15 

Swap  091750-301  S/N 
0100524  with  S/N 
0100660  from  EPU  15 

Flew  2  failure  Free 
Sorties  @  NAS  New 
Orleans 

Sent  Out 

Temp 

Amb.. 

Cycles 

Amb.. 

Part  Number 

9058027-1  OROR 

S/N 

0290481 

Shop  Order 

W083214 

Present  loc. 

NDMP  Receiving 

Date 

6/26/2000 

9/11/2000 

9/18/2000 

11/14/2000 

11/22/2000 

1/10/2001 

1/30/2001 

Failure 

HIDC  intermittent 

DCS  1-6 

No  Failures  Unit 
Passes  all  Tests 

Action 

Clean  Mother  Board 

Swap  091250-302 

S/N  0200720  with  S/N 
0290619  From  EPU 

15 

Flew  2  failure  Free 
Sorties  @  NAS  New 
Orleans 

Sent  Out 

Ran  atp  and  flight  sim 
during  cycles  no 
failures  reported 

sent  out 

Temp 

Cold 

Cold 

various 

Part  Number 

9058027-1  OROR 

S/N 

0290231 

Shop  Order 

W083216 

W087690 

Present  loc. 

Para 

Date 

6/26/2000 

7/5/2000 

7/24/2000 

7/27/2000 

8/7/2000 

9/11/2000 

Failure 

Multiple 

Vib  Failures 

Vib  Failures 

Multiple 

No  cold  Boot 

Vib  Failure  1.2  sb  < 

0.5 

Action 

R/R  U3  on  091460- 
301 

Clean  Mother  Board 

R/R  C28  on  091800- 
305  Wire  43 
pinched  on  091760- 
304 

R3,U3,C1  on  091460- 
301 

U3  on  091800-305 
Swap  091750-301  S/N 
0190189  with  S/N 
0100524  from  EPU  15 

Swap  091460-301 

S/N  0190163  with 
091450-310  S/N 
1000309  from  EPU 

15 

Temp 

Amb.. 

Cycles 

Cycles 

Cold 

Amb. 

Cycles 

Date 

9/13/2000 

12/4/2000 

1/10/2001 

Failure 

Failed  @  NAS  New 
Orleans 

Action 

Sent  Out 

Failed  initially 
@NDMP  but  then 
never  failed  again 

Sent  Out 

Temp 

Part  Number 

9058027-1  OROR 

S/N 

0290015 

Shop  Order 

W083213 

Present  loc. 

NDMP  Test 

Date 

7/5/2000 

9/5/2000 

9/11/2000 

1/11/2001 

2/5/2000 

Failure 

Left  Thermal  Couple 

Multiple 

Multiple 

Action 

Swapped  091020-301 
S/N  0190793  with  S/N 
0100276  From  NDMP 
Test 

Clean  Mother  Board 

swapped:  091450- 
310,  091300-302, 
091750-301,  091250- 
302 

R/R  R11  on  091250 

R/R  CR15  on  091800 
R/R  C17.C18  on 

091300 

Ready  for  retest 

Ready  to  ship 

Temp 

Amb.. 

Amb 

various 

1 
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2.4  FFSCU  TPS 


A  subcontract  was  placed  with  TRW  SAEO  for  the  development  of  a  Test  Program  Set 
(TPS)  for  the  TEMS  Fuel  Flow  Signal  Conditioning  Unit  (FFSCU).  The  FFSCU  TPS  would 
enable  the  Air  Force  to  have  organic  screening  capability  for  FFSCU  units,  a  capability  that  was 
not  in  place  at  the  time.  All  units  returned  from  the  field  had  to  be  sent  back  to  the  OEM  for 
repair.  The  FFSCU  TPS  was  designated  to  be  developed  on  the  IABIT  tester. 

Under  this  effort,  typical  test  program  set  development  milestones  were  established,  including 
Software  Requirements  Review  (SRR),  Test  Strategy  Document  (TRD)  development, 
Preliminary  Design  Review  (PDR)  and  Critical  Design  Review  (CDR),  as  well  as  appropriate 
milestones  for  Technical  Manual  development. 

TRW  expended  all  funding  on  this  effort  before  being  able  to  deliver  an  end  product.  The  Air 
Force  was  not  able  to  secure  the  additional  funding  required  to  complete  the  project. 

The  IABIT  tester  was  subsequently  put  out  of  service  by  the  Air  Force,  since  it  was  inoperable. 
GAC  created  a  TPS  for  the  FFSCU  FRU  on  the  APST  test  system  in  Warner  Robins  AFC,  and 
the  Air  Force  now  has  an  organic  capability  to  test  and  verify  the  FFSCU  assembly. 

2.5  WinDDU  Software  Port 

A  subcontract  was  placed  with  TRW  SAEO  for  porting  the  DOS-based  TEMS  Data  Download 
Unit  (DDU)  software  to  a  modern,  Windows  software  environment.  This  included  re-design  and 
re-hosting. 

The  Win  DDU  software  was  completed  and  delivered  to  the  Air  Force  by  TRW.  Subsequently, 
certain  test  problems  and  field  correlation  problems  were  seen  and  recorded  which  are  being 
corrected  by  OC-AFC  engine  management  group  as  they  apply  to  engine  test  algorithm 
anomalies. 

2.6  Flight  Simulation  Software 

A  subcontract  was  placed  with  TRW  SAEO  for  porting  and  enhancing  the  TEMS  flight 
simulation  software,  which  resided  on  the  TEMS  OEM’s  tester  called  the  “Foop  Tester”  to  a 
modem  test  environment.  The  Flight  Simulation  program  would  have  allowed  the  Air  Force  to 
perform  dynamic  testing  of  the  TEMS  EPU  by  simulating  the  inputs  that  the  EPU  receives  in  the 
operational  environment.  The  result  would  have  been  a  much  more  extensive  test  capability  for 
the  EPU.  This  effort  was  being  hosted  on  the  IABIT  test  system  at  WR-AFC.  The  IABIT  tester 
was  subsequently  put  out  of  service  by  the  Air  Force,  since  it  was  inoperable. 

TRW  expended  all  funding  on  this  effort  before  being  able  to  deliver  an  end  product.  The  Air 
Force  was  not  able  to  secure  the  additional  funding  required  to  complete  the  project. 
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2.7  TEMS  EPU  Processor  Card  TPS  Development 


A  test  program  set  was  developed  for  the  EPU  Processor  card  and  a  re-engineered  version  of  the 
Processor  card.  A  test  program  had  not  previously  been  available  for  the  processor  card,  so  this 
resulted  in  a  new  and  improved  test  capability  for  the  depot. 


GAC  created  a  TPS  for  the  Slot  A9  processor  card  on  the  MATE  390  test  system  in  Warner 
Robins  ALC,  and  the  Air  Force  now  has  an  organic  capability  to  test  and  verify  as  well  as 
diagnose  and  repair  the  processor  assembly  for  the  KC-135  and  A10  EPU  assemblies. 

The  test  program  set  included  full  documentation  and  was  successfully  sold  off  (verified  and 
accepted)  at  Warner  Robins  Air  Logistics  Center  depot  operations.  A  software  Computer 
Program  Identification  Number  (CPIN)  was  provided  and  delivered,  fault  insertion  diagnostics 
were  performed  and  verified  to  support  a  diagnostic  repair  capability,  and  supporting  Test 
Program  Instruction  (TPI)  tech  orders  were  provided  and  delivered. 
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3.o  TEMS  Modernization  /  Replacement 

The  Turbine  Engine  Monitoring  System  (TEMS)  is  currently  used  in  the  A- 10  and  KC- 
135  aircraft.  TEMS  is  a  25-year-old  technology  system .  Obsolescence  of  individual  components 
is  rendering  it  unsupportable. 

This  system  utilizes  one  Electronic  Processing  Unit  (EPU)  in  the  A- 10  and  two  in  the  KC-135. 
The  three  housings  and  cable  connectors  are  identical.  The  differences  are  the  aircraft  and  engine 
sensor  signals  received  from  the  two  engines  on  the  A- 10  and  the  four  engines  on  the  KC-135. 

The  TEMS  EPU  houses  the  electronics  that  samples,  digitizes,  and  stores  analog  signals  received 
from  engine  and  aircraft  sensors.  Due  to  the  nature  and  function  of  the  referenced  weapon 
systems,  the  range  of  interest,  magnitude,  frequency,  and  quantity  of  sensed  signals  are  not 
identical. 

In  the  current  configuration  of  TEMS,  the  operating  system  (O/S)  and  decision-making, 
algorithmic,  programs  are  stored  as  firmware  in  EPROMs  in  the  EPUs.  Sensed  parameter  limit 
values  and  reference  constants  are  stored  in  RAM.  The  TEMS  EPU  performs  algorithmic  activity 
and  stores  all  sensed  data  values  when  certain  conditions  are  satisfied.  At  three  points  in  the 
flight  profile,  TAKEOFF,  CLIMB,  and  CRUISE,  the  data  is  stored  if  the  algorithmic  activity 
senses  certain  parameters  are  within  stored  data  limits.  For  51  other  weapon  system  operating 
conditions,  the  data  is  stored  if  certain  parameters  are  fixed  outside  stored  data  limits  (EVENTS). 

Besides  storing  the  three  automatic  data  points,  the  existing  system  stores  data  generated  by  an 
EVENT  only  once.  Triggered  by  a  switch  in  the  cockpit,  data  storage  can  be  initiated  by  the 
Pilot.  Data  from  multiple  flights  can  be  stored  between  downloads. 

The  limit  values,  called  CALMEM,  and  Actuarial  data  are  stored  in  RAM  with  the  “Initializing” 
process.  This  process  transfers  these  constants  to  the  TEMS  EPU  via  ground  support  equipment 
(GSE).  “Downloading”  is  the  existing  process  whereby  GSE  is  used  to  retrieve  the  stored  flight 
data. 

The  current  EPU  uses  aircraft  28  VDC  aircraft  power.  It  is  also  designed  with  battery  backup  to 
retain  volatile  RAM  memory.  The  existing  module  is  not  pressurized  but  open  to  the  atmosphere. 
These  latter  two  features  along  with  the  EPROMs,  8055  Processor,  data  sampling  speed, 
component  obsolescence,  and  seventies  signal  conditioning  technology  contribute  to  excess 
system  operating  costs. 

Under  this  contract,  a  series  of  tasks  were  performed  to  derive  a  suitable,  cost-effective  candidate 
for  the  replacement  of  the  TEMS  system. 
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3.1  TEMS  COTS  Replacement  Market  Survey 

A  Market  Survey  was  performed  to  determine  the  availability  of  candidate  replacement  systems 
on  a  Commercial  Off-the-Shelf  (COTS)  basis. 

A  pre-cursor  to  the  actual  Market  Survey  was  the  definition  and  documentation  of  critical 
performance  parameters  for  the  TEMS.  This  resulted  in  a  TEMS  Performance  Specification  that 
was  then  converted  to  a  Commercial  Item  Description  (CID). 

The  Market  Survey  was  primarily  performed  by  TRW  SAEO.  The  market  survey  included 
soliciting  inputs  from  vendors  to  understand  the  capabilities  of  available  commercial  flight  data 
recorders  that  may  be  capable  of  performing  the  tasks  required  for  a  replacement  of  the  TEMS. 
This  survey  included  contact  with  industry  associations,  vendors,  literature  search,  brochure  and 
catalog  reviews,  and  on-line  searches.  The  results  of  the  survey  were  then  analyzed  against  the 
previously  defined  performance  parameters. 

The  results  of  the  Market  Survey  are  documented  in  a  Market  Survey  report.  The  market  survey 
was  specifically  targeted  towards  the  availability  of  a  COTS  replacement  of  the  TEMS  on  the  A- 
10  aircraft.  The  market  survey  determined  that  there  are  no  systems  that  could  replace  the  TEMS 
on  the  A- 10  without  a  Non-Recurring  Engineering  (NRE)  effort.  The  survey  also  found  that  there 
were  no  systems  currently  offered  that  are  designed  with  open  architecture  standards  that  satisfy 
the  goal  of  long-term  non-obsolescence. 

A  questionnaire  was  developed  to  identify  key  technology  areas  and  vendor  capabilities  in  order 
to  assess  the  potential  for  having  the  A- 10  TEMS  requirements  satisfied  using  COTS  or  primarily 
COTS-based  solutions. 
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Table  4  -  Market  Survey  Questions 


1 

Model  Name? 

2 

Part  Number? 

3 

Flight  Certified?  (Y/N/Pending) 

4 

A/C  used  on? 

5 

Number  of  Analog  Input  Channels? 

6 

Are  Analog  Inputs/Channels  Configurable?  (Y/N) 

7 

If  Q6  is  Yes,  to  what  extent  are  analog  channels  configurable?  0-10V,  0-1V,  0-100  mv,  4-20  ma  ,etc. 

8 

Number  of  Discrete  Input  Channels? 

9 

Are  Discrete  inputs/channels  configurable?  (Y/N) 

10 

If  Q9  is  Yes,  to  what  extent  are  discrete  inputs/  channels  configurable?  0-5 V,  0-28 V,  dry  or  wetted 
contacts, 

11 

Number  of  Thermocouple  Channels? 

12 

Types  of  Thermocouples  supported? 

13 

Number  of  Synchro  Channels 

14 

Number  of  accelerometer  pickup  channels  supported? 

15 

Can  system  measure  narrow  band  and  wide  band  vibration  on  each  channel?  (Y/N) 

16 

Number  of  RPM  /  frequency  measurement  channels? 

17 

Number  of  Mil  STD  1553  buses  provided? 

18 

What  1553  modes  are  supported?  Full/RT/Other 

19 

What  is  system  memory  size  In  MB? 

20 

What  is  trending  data  storage  memory  size  in  MB? 

21 

What  standard  configuration  interfaces  are  supported? 

22 

What  is  the  ADAS  unit’s  power  consumption  in  Watts? 

23 

What  is  the  weight  of  the  unit,  in  lbs? 

24 

What  is  the  unit’s  MTBF? 

25 

How  is  the  MTBF  Determined? 

Is  it  based  on  calculation  or  demonstration? 

26 

What  altitude  is  the  unit  rated  for?  (in  Feet) 

27 

What  is  the  humidity  specification  limits  for  the  ADAS  unit? 

28 

What  are  the  Vibration  Limits  for  the  unit? 

29 

What  are  the  shock  vibration  limits  for  the  ADAS  unit? 

30 

What  are  the  temperature  (op/  storage)  range/  limits  for  the  ADAS  unit? 

31 

What  Operating  System  does  the  ADAS  unit  use? 

32 

What  software  programming  languages  does  the  unit  use? 

33 

Is  the  embedded  application  software  proprietary? 

34 

How  is  ADAS  configured?  Laptop/  Peculiar  Device.  (L/P) 

35 

Is  the  ADAS  unit  ground  support  software  proprietary  or  can  source  code  be  provided? 

36 

How  is  ADAS  configuration  data  retained?  Battery,  Flash,  EPROM  or  other. 

37 

If  other,  What  technology  is  used? 

38 

Can  embedded  application  be  updated  via  hardware  I/F  or  is  it  contained  in  firmware?  (U/F) 

39 

How  many  years  in  service? 

40 

Does  system  have  an  A/C  mounted  interface  for  interrogating  ADAS  status? 

41 

Where  is  this  ADAS  system  designed  to  be  mounted? 

42 

What  are  the  dimensions  of  the  ADAS  unit? 

43 

What  is  the  warranty  for  this  ADAS  unit? 

44 

Does  the  ADAS  contain  a  built  in  test  (BIT)? 
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45 

Does  the  unit  have  calibration  requirements? 

46 

Is  a  repair  facility  available  for  this  system? 

47 

What  is  the  Cost  of  the  standard  ADAS  unit? 

Table  5  summarizes  the  information  collected  for  the  vendors  who  have  requested  the 
questionnaire  in  order  to  provide  data  for  potential  candidate  solutions. 


Table  5.  TEMS  Source/Vendor  List 


VENDOR  INFORMATION 

CAGE  CODE 

MODEL  NO. 

PART  NO. 

AMETEK 

50  Fordham  Rd, 

Wilmington,  MA  01887 

4A887 

EMSC 

8KE124 

AVM 

8KE143 

EAU 

8KE131 

SCDU 

8KE89 

BAE  Systems  -  Canada 

415  Legget  Dr., 

PO  Box  13330 

Kanata,  Ontario, 

Canada  K2K2B2 

38753 

CMA-2074MC 

(TBD) 

CPU-Tech 

4900  Hopyard  Rd.,  Ste  300 
Pleasanton,  CA  94588 

0XRH7 

Honeywell-Altair 

106  Access  Rd., 

Norwoord,  MA  02062 

08CZ0 

TrendCheck 

TREND-A-0 10-1 

ADAS 

TWIN-A-010-1 

IntelliStart+ 

DPU-A-010-1 

NIU 

2118908-4 

Hamilton-  Sunstrand 

One  Hamilton  Rd., 

Windsor  Locks,  CN  06096 

6H521 

SDC200-20 

791660-30 

DAS  100-1 

R-NET  Engineering  & 

Technologies 

PO  Box  2418 

Cedar  Rapids,  IA  52406 

1P1T5 

ADAPTS-B 

ADAPTS- 10 

ADAPTS- 16 

ADAPTS-CBM 

SBS  Technologies 

2400  Louisiana  Blvd.,  NE 
Albuquerque,  NM  87110 

0BAS8 

Smiths  Industries 

3290  Patterson  Ave.,  SE 

Grand  Rapids,  MI  49512 

0B0W7 

Voice  and  Data 
Recorder  (VADR) 

3253A 

3253C 

3253E 

3253F 

Teledyne  Controls 

16151  NE,  113th  Court 

Redmond,  WA  98052 

98571 

DFDMU 

DMU 

FDAU 

FDIMU 

MDAU 

MFDAU 
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3.2  TEMS  Replacement  Weapon  System  Survey 


Towards  the  end  of  the  Market  Survey  effort,  Air  Force  senior  management  direction  was 
given  to  emphasize  and  pursue  system  architectures  that  could  be  used  across  multiple  aircraft 
platforms  using  open  architecture  concepts.  Additionally,  direction  was  put  forth  to  identify 
additional  Air  Force  aircraft  platforms  that  were  experiencing  the  same  obsolescence  issues,  as 
was  TEMS,  and  to  define  a  system  that  could  be  used  on  a  common  basis. 

The  concept  was  that  TEMS  replacement  could  be  the  first  step  in  improved  aircraft  readiness 
and  maintenance  across  AF  weapon  systems  by  taking  advantage  of  25  years  growth  in 
technology.  KC-135  and  A- 10  are  the  first  TEMS-like  systems  to  face  the  challenges  of 
obsolescence.  Other  TEMS-like  applications  implemented  over  the  past  two  decades  will  face 
similar  obsolescence  over  time.  Some  aircraft  have  either  no  monitoring  capability  or  limited 
monitoring  capability.  TEMS  replacement  for  A- 10  /  KC-135  can  lead  to  many  new  and  exciting 
opportunities  for  the  AF  propulsion  and  support  communities.  Updated  TEMS  hardware 
facilitates  extended  utilization/processing  of  parametric  data  such  as  life  usage  indicators, 
anomaly  detection  and  snapshot,  embedded  diagnostics,  prognostic  indications  and  trend  analysis. 
The  opportunities  presented  by  a  redesigned  TEMS  include  developing  a  common  core  module, 
open  architecture,  accommodate  legacy  systems  while  allowing  enhanced  diagnostic/prognostic 
processing,  data  reduction  through  intelligent  processing,  significantly  reduced  ground  support 
equipment  and  significantly  reduced  support  costs.  Other  opportunities  include  joint  service 
applicability  and  interest,  expanded  functionality,  expanded  memory  and  expanded  intelligence  in 
ground  processing. 

In  the  course  of  the  survey,  program  offices  (SPOs)  were  contacted  and  the  following  information 
was  attempted  to  be  gathered  and  characterized: 

•  Does  the  system  currently  have  a  Data  Acquisition,  Analysis,  and  Forecasting  System 
capability? 

•  If  not,  is  a  Data  Acquisition,  Analysis,  and  Forecasting  System  capability  warranted? 

•  Is  the  program  office  receptive? 

•  How  are  engine  diagnostics  and  trending  currently  accomplished? 

•  If  a  Data  Acquisition,  Analysis,  and  Forecasting  System  capability  is  in  place: 

■  What  is  the  age  of  the  current  system 

■  Are  there  obsolescence  issues?  Supportability  issues? 

■  What  sensors  are  incorporated? 

■  Is  there  a  data  bus  in  the  system? 

■  Is  the  Data  Acquisition,  Analysis,  and  Forecasting  System  used  for: 

•  Engine  Go/No-Go  at  flight  line 

•  Engine  Diagnostics  at  flight  line 

•  Input  to  Comprehensive  Management  System  (CEMS) 
IV/Comprehensive  Engine  Testing  and  Diagnostics  System 
(CETADS)? 

■  Who  is  the  Primary  Focal  Point  concerning  this  Data  Acquisition, 
Analysis,  and  Forecasting  System? 

■  How  long  is  the  aircraft  expected  to  be  operational? 

■  Is  there  interest  in  updating  the  Data  Acquisition,  Analysis,  and 
Forecasting  System? 
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As  a  result  of  the  survey,  several  aircraft  platforms  were  identified  that  had  a  need  for  a 
modernized  data  acquisition  system.  These  include  F-16,  F-15,  KC-10,  F-l  17. 


3.3  UDAS  Specification 

Based  on  the  re-direction  from  senior  Air  Force  management,  the  program  was  re-cast  to  develop 
a  concept  and  system  architecture  that  could  be  adapted  across  multiple  aircraft  platforms, 
without  requiring  expensive  wiring  and  connector  changes  to  the  aircraft. 

At  the  same  time,  the  A- 10  SPD  opted  out  of  a  replacement  system  for  TEMS,  opting  instead  for 
short-term  fixes  to  the  TEMS  EPU.  Additionally,  KC-135  planned  a  consolidation  of  data 
acquisition  functions  into  a  single  recorder,  and  retirement  of  the  TEMS  system  from  use  on  the 
KC-135.  The  F-16  aircraft  was  facing  immediate,  critical  need  for  a  replacement  of  the  F-16 
Crash  Survivable  Flight  Data  Recorder  (CSFDR)  and  strongly  supported  the  open  architecture 
concepts.  The  program  was  re-focused  on  this  F-16  requirement. 

A  system  concept  was  defined  for  a  Universal  Data  Acquisition  System  (UDAS).  UDAS 
consisted  of  a  common  core  of  those  elements  that  were  common  to  any  flight  data  acquisition 
system,  and  an  aircraft  interface  module,  which  were  the  unique  elements  that  adapted  the  overall 
system  to  the  requirements  and  interfaces  of  a  specific  aircraft  platform. 

A  performance  specification  was  developed  defining  this  overall  system  concept  and  architecture. 
The  specification  included  a  primary  specification  for  the  overall  architecture  and  the 
requirements  of  the  common  core,  and  was  augmented  with  a  platform  specific  specification.  The 
F-16  CSFDR  replacement  was  selected  as  the  target  application  as  a  proof  of  concept.  Therefore, 
the  platform  specific  specification  reflected  the  specific  requirements  for  replacement  of  the  F-16 
CSFDR  by  a  universal  data  acquisition  system. 


3.4  UDAS  RFI  &  RFP 

Based  on  a  system  description  and  the  specifications  described  in  the  previous  section,  a 
Request  for  Information  (RFI)  was  developed  and  released  to  industry  through  the  Commerce 
Business  Daily  (CBD).  The  intention  of  the  RFI  was  to  identify  potential  Industrial  Sources  for  a 
system  as  defined  in  the  specifications,  and  to  validate  the  system  concept  by  soliciting  comments 
and  specific  technical  approaches. 

Many  responses  were  provided  to  the  RFI.  The  RFI  responses  were  also  used  to  determine  if  it 
would  be  feasible  for  our  program  to  solicit  proposals  for  the  development  of  a  prototype  UDAS 
system  (e.g.,  were  there  enough  funds  remaining  to  develop  the  prototype.)  The  RFI  responses 
were  also  used  to  refine  the  specification,  identify  risks,  and  to  develop  a  statement  of  work  for 
the  development  of  the  prototype. 

As  a  result  of  the  RFI  results,  it  was  determined  that  is  was  indeed  feasible  to  develop  a  UDAS 
prototype.  A  full  set  of  procurement  documents  was  developed  and  compiled  into  an  RFP 
package.  An  RFP  was  released  to  industry  via  an  announcement  in  the  Commerce  Business 
Daily. 

Eight  proposals  were  submitted  in  response  to  the  RFP.  An  extensive  evaluation  of  the  proposals 
was  conducted.  Only  one  company’s  proposal  met  the  full  set  of  technical  requirements  and  was 
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within  the  cost  range.  A  subcontract  was  awarded  to  R-Net  Engineering  and  Technology  for  the 
development  of  a  prototype  UDAS  system  that  would  target  the  replacement  of  the  F-16  CSFDR. 


18 


3.5  UDAS  Prototype  Development,  Test  &  Validation 


A  subcontract  was  awarded  to  R-Net  Engineering  and  Technology  for  the  development  of 
a  prototype  UDAS  system  that  would  target  the  replacement  of  the  F- 16  CSFDR.  The  overall 
purpose  of  the  prototype  development  was  to  serve  as  a  proof  of  concept  and  validation  of  the 
UDAS  specification,  and  at  the  same  time,  to  develop  a  system  that  would  serve  as  a  feasible 
candidate  replacement  for  the  F- 16  CSFDR. 

The  UDAS  was  tested  on  the  F-16  CSFDR  hotbench  facility  at  Lockheed  Martin  in  Ft.  Worth, 
Texas.  The  testing  verified  the  functionality  and  feasibility  of  the  UDAS. 

The  following  provides  a  description  of  the  results  of  this  prototype  development  effort. 


3.5.1  Universal  Data  Acquisition  System  (UDAS)  Program  Summary 

UDAS  is  a  data  acquisition  system  that  is  being  developed  as  an  open-architecture  device  that  can 
be  adapted  to  any  aircraft  application.  In  the  current  application,  it  is  being  targeted  as  a  form- fit 
function  replacement  for  the  F-16  CSFDR.  For  this  application,  all  F-16  blocks  will  be 
accommodated  using  a  single  design,  which  reconfigures  to  the  specific  block  aircraft  TMS  via 
software. 

UDAS  uses  the  latest,  state-of-the-art  technology  for  architecture,  system  memory,  data 
processing  and  storage,  and  crash  survivable  memory.  It  has  system  hooks  for  the 
implementation  of  wireless  transmission  of  signals  and  data,  as  well  as  video  and  audio  data 
collection  and  storage. 

Our  goal  in  the  UDAS  program  is  to  significantly  reduce  the  cost,  and  improve  the  long-term 
supportability  posture  of  data  recording  systems  including  Crash  Survivable  Flight  Data 
Recorders  through  the  use  of  standard  open  architecture  design  concepts  applied  to  the  hardware 
and  software  of  the  device.  It  is  also  to  define  and  substantiate  an  architecture  that  is  readily 
adaptable  to  any  aircraft  platform  needs  via  augmentation  of  the  core  (common)  hardware  and 
software  elements  with  aircraft-unique  elements. 

The  UDAS  design  is  based  on  the  use  of  commercial  design  standards  in  a  ruggedized,  military 
environment.  PC/ 104-Plus  architecture  is  used  with  a  Linux  Operating  system. 
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3.5.2  UDAS  Program  Accomplishments 

The  UDAS  Program  has  completed  the  development  of  the  common  core  UDAS  data  acquisition 
system,  and  has  developed  a  prototype  that  is  specifically  designed  to  meet  the  requirements  of 
the  F-16  Crash  Survivable  Flight  Data  Recorder  (CSFDR).  The  unit  has  been  tested  on  the 
CSFDR  hotbench  facility  at  Lockheed  Martin  and  successfully  read  simulated  flight  profiles  and 
performed  data  handling  correctly. 

The  accomplishments  in  the  UDAS  development  effort  include  the  following: 


Open  Architecture  Design  with  “Common  Core”  that  can  be  applied  to  multiple  aircraft 
applications 

Designed  around  Open  Industry 
standards  (PC/ 104,  Linux) 

Common  Design  and  Support 
Infrastructure 
“True”  COTS  (no  mods) 

Form-Fit-Function  Replacement  with 
NO  Aircraft  Mods 
Built-in  Non-Obsolescence 
Significantly  Reduced  Costs 
N  on-Proprietary 

Easily  Expandable  through  Plug  & 

Play 

NOT  “One  Size  Fits  All  ”  -  Re- 
Configurable  to  platform 
requirements 

Use  of  signal  and  parameter  names 
that  can  easily  be  read  by  people 
(English  language  in  engineering 
units). 


3.5.3  Adaptable  Design  for  Multiple  Aircraft  Applications 


Common  Data 

Host  Aircraft 

Acquisition  Module 

Interface  Module 

(CDAM) 

(AIM) 

•  Hardware 

+ 

•  Hardware 

•  Software 

•  Software 

•  CSM  (if  required) 

Includes... 

-CPU 

-  System  memory 

-  Power  Supply- 

-  Operating  System 

-  I./O  Card  Driver  Library 

-  Data  Processing 

-  Data  Analysis 


Includes... 

-  Electronic  Interface  (I/O  Cards) 

-  Physical  Interface 

-  Processor  enclosure 

-  CSM  mounting 

-  System  I/O  Configuration 

-  Unique  Data  Analysis 


Host  Aircraft 
UDAS 
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3.5.4  UDAS  Data  Structures  /  Data  Handling 

Generic  data  structures  have  been  designed  to  accommodate  the  requirements  of  the  AF  AIP 
(Aircraft  Information  Program).  These  data  structures  allow  collection  of  all  data  into  a  matrix 
format,  and  extraction  of  required  data  for  off-line  processing  routines  via  simplified  queries 
against  the  matrix. 

The  graphic  below  illustrates  the  flow  of  data  into,  through,  and  from  the  UDAS  system.  Raw 
data  can  come  from  digital  data  buses  such  as  the  MIL-STD-1553  avionics  and  weapons  digital 
data  buses,  from  wireless  sensors,  and  from  wired  (copper  or  optical)  sources. 


Digital  Data  Buses 

(1553,  Weapons) 

Wired  Sensors 

(A/D,  Discretes) 

Wireless  Sources 

(Eng  Vib,  Fuel  Coni) 

1 

1 

1 

f 

High  Speed  Archiving  of 

Raw  Data 

(Crash  Survivable  Memory) 

DownLoadab 

Raw  Data  I  I 
Organized  Data  | 
Information  Q 


Di  agnosis/P  rognosis 
Information 


Diagnosis/Prognosis 

Information 


Wireless 


Wired  Removable 


J  S. 

Serial 


t 


SB  Memory 

Stick 


PCMCIA 

Card 


El  hern  el 


Raw  data  is  digitized  as  needed  and,  if  desired,  selected  raw  data  is  routed  to  crash  survivable 
memory  before  any  processing  occurs.  Initial  data  processing  involves  transforming  the  raw  data 
into  readable,  engineering  units,  associating  each  data  stream  with  its  sensor  source,  time  tagging 
the  data,  and  then  entering  all  data  from  all  sources  into  a  time-source  correlated  database.  This 
time-source  data  is  then  stored  in  non-volatile  memory.  Archived  data  that  had  been  loaded  into 
the  UDAS  system  prior  to  flight  is  also  moved  to  the  database  to  facilitate  prognostic  analysis. 
The  correlated  data  is  then  processed  to  produce  diagnostic  and  prognostic  information  and  the 
processing  results  transferred  to  the  non-volatile  memory.  The  correlated  data  and  information 
can  be  downloaded  in  whole  or  in  selected  parts  via  data  radios  in  real  time  or  after  landing  using 
wireless  hand  held  device,  through  a  standard  serial  connector,  and/or  through  removable 
memory.  Information  can  also  be  routed  back  to  the  aircraft  system  through  the  digital  data 
buses. 


Data  source  methods  (digital  data  bus,  wireless,  wired)  are  selectable  for  the  original  design  and 
equipment.  Additional  data  source  methods  and  data  streams  can  be  added  as  needed  after  the 
equipment  is  initially  installed.  The  data/information  download  method  can  also  be  selected 
initially  and  changed  after  installation.  Data  analysis  processes  are  changed  as  needed  by 
software  update. 
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3.5.5  UDAS  System  Architecture 


The  UDAS  system  employs  the  PC/1 04+  with  a  32-bit  PCI  backplane .  The  PC- 104  architecture 
features: 

•  Self-stacking  modules  104-pin  and  120-pin  PCI  bus  connectors  to  allow  multiple 
modules  to  be  added  to  the  system  with  out  the  burden  of  backplanes  and  cartridges. 

•  Minimized  size  (3.6  x  3.8  in) 

•  Low  power  consumption  (typically  1-2  watts  per  module) 

•  VCHOA-Plus  technology  is  compatible  with  PC/104  and  supports  32-bit  PCI  interconnect 

•  Consortium  companies  with  company  products  and  specifications 


Standalone  module  stacks.  As  shown  in  the  figure,  PC/ 104  modules  are  self-stacking.  In  this 
approach,  the  modules  are  used  like  ultra-compact  bus  boards,  but  without  needing  backplanes  or 
card  cages.  Stacked  modules  are  spaced  0.6  inches  apart.  (The  three-module  stack  shown  in  the 
figure  measures  just  3.6  by  3.8  by  2  inches.)  Companies  using  PC/104  module  stacks  within  their 
products  frequently  create  one  or  more  of  their  own  application-specific  PC/ 104  modules. 


The  x86-based  PC  has  made  an  enormous  impact  in  the 
computing  world  that  has  spilled  into  the  industrial  and 
non-desktop  market  as  well.  The  PC  architecture  has 
become  the  dominant  standard  that  has  worked  its  way  into  applications  never  dreamed 
of  by  its  designers.  The  reason  is  that  an  embedded  PC  can  reduce  development  costs  and 
accelerate  their  time  to  market.  The  standard  it  brings  is  more  than  just  bus  timing  or 
packaging.  PC-compatibility  means  a  definition  of  the  internals  of  a  system  including  the 
CPU  family,  DMA,  interrupts,  timing,  serial  ports,  LAN  interfaces,  video,  disk  storage, 
etc.  The  bottom  line  is  that  the  PC  has  become  firmly  embedded  as  a  standard  design 
element  in  a  wide  variety  of  applications. 


Introduction  of  PC/104 

Embedded  designers  have  reaped  a  bonanza  from  the  PC.  One  of  the  finest  examples  is  the 
PC/104  architecture  whose  first  specification  was  published  in  1992.  Key  features/benefits  are 
that  the  modules  are  compact,  modular,  self-stacking,  and  PC-compatible  offered  in  a  variety  of 
functions  with  multi-vendor  support.  Also,  there  is  an  active  Consortium  to  maintain  and  improve 


1  Excerpted  from  a  White  Paper  by  Robert  A.  Burckle,  VP,  WinSystems,  Inc. 
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the  technical  standards  plus  promote  worldwide  industry  visibility. 


PC/ 104  is  a  repackaged,  modular  version  of  the  PC  architecture  intended  for  embedded 
applications  where  space,  power  consumption  and  reliability  are  critical.  These  modules 
can  serve  as  a  mezzanine  bus  for  an  embedded  System  Bus  Controller  (SBC)  or  it  can 
become  the  entire  computer  and  I/O  system. 

A  PC/ 104  module  is  an  Industry  Standard  Architecture  (ISA)  bus  board  reduced  to  3.6  x 
3.8-inch  (90  x  96-mm)  that  is  approximately  the  size  of  a  3.5-in  diskette.  The  bus  signal 
definitions  and  timing  are  the  same.  PC/104?s  PI  bus  has  64  pins  just  like  the  PC-XT  and 
is  combined  with  40-pins  on  P2  for  full  AT-compatibility.  The  sum  of  the  pins  (64  +40  = 
104)  is  the  origin  of  the  name  PC/ 104. 

PC/104-Plus 

The  original  PC/ 104  bus  has  done  a  great  job  of  supporting  the  16-bit  ISA  standard. 
However,  certain  applications  require  greater  throughput.  Therefore,  PC/ 104-Plus  was 
defined  and  standardized.  It  is  the  32-bit  standard  migrated  from  the  desktop  to  the 
embedded  world  while  still  offering  the  same  capabilities. 

PC/1 04-Plus  is  a  PCI  implementation  on  a  stackable  board  while  maintaining  the  3.6”  x 
3.8”  form  factor.  PC/  104-Plus  modules  can  also  include  original  PC/ 104  connectors  to 
allow  the  most  system  configuration  flexibility.  PCI  was  chosen  for  a  number  of  reasons. 
First  it  is  the  de  facto  standard  for  desktop  32-bit  transfers  that  significantly  improves 
throughput  between  cards.  Next  PCI  is  a  known  and  proven  standard.  It  is  an  open 
architecture  that  is  well  documented  with  no  licensing  requirements.  Finally,  PCI  is 
supported  by  current  and  next  generation  integrated  circuits.  Even  FPGAs  have  the  PCI 
interface  available  to  license  as  Intellectual  property  for  custom  designs. 

The  key  to  success  of  the  PC/ 104-Plus  again  lies  in  the  connector  scheme.  A  third 
connector  is  added  opposite  the  PC/104  PI  and  P2  connectors.  It  is  a  4  x  30  (120-pin)  2- 
mm  pitch  stackthrough  connector  (as  opposed  to  the  124-pin  card  edge  connector  on  a 
standard  32-bit  PCI  card).  A  shroud  covers  the  male  pins  of  the  connector  and  guides  it  to 
the  next  connector  in  the  stack.  The  PC/  104-Plus  connector  fits  between  the  mounting 
holes.  Spacing  of  the  stacked  modules  is  maintained  at  0.6  inches. 

Actual  data  throughput  for  the  PCI  bus  is  at  least  an  order  of  magnitude  greater  than  the 
ISA  bus. 
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3.5.6  UDAS  System  Processor 
ADL  PHI  MSMP3/SEV 

•  700  MHz  CPU  (1 .2-2.4  GHz  early  CY  04) 

•  Power  management 

•  256  Mbytes  RAM 

•  3  video  input  channels 

•  100  Base-T  Ethernet 

•  2  USB  Ports  (supports  hard  drives) 

•  2  Serial  Ports  (RS-232  or  RS-422) 

•  PC/1 04+  (ISA  and  PCI  backplanes) 

•  IDE  bus  for  hard  drives 

•  -32C  to  +71C  -  tested  to  95°  C 

3.5.7  System  Memory 


UDAS  System  Memory  is  a  2-Gigabyte  hard  drive  packaged  as  a  Type  II  PCMCIA  card.  The 
PCMCIA  card  is  will  contain  the  necessary  configuration  files  to  identify  the  type  of  aircraft 
configuration  that  the  UDAS  is  to  initialize  to. 

The  card  is  removed  after  flight  as  the  method  of  data 
download,  thus  eliminating  the  need  for  serial 
download  at  the  flightline. 

The  system  memory  has  the  following  characteristics: 

•  Temperature  Range  — 40C  to  +85C 

•  Vibration  -  1 5G  peak  to  peak 

•  Shock-  1000G 

•  Altitude  -  80,000  ft. 

•  Reliability  -  >1,000,000  hrs 

•  Capacity  -  2GBytes 

3.5.8  Data  Download 

Download  of  data  from  UDAS  to  ground 
systems  for  processing  can  be 
accomplished  in  many  ways,  using  either 
wireless,  wired,  or  removable  memory. 

For  the  F- 16  application,  a  PCMCIA  card 
is  being  used  such  that  the  card  can  be 
quickly  removed  from  the  system,  and  a 
new  card  inserted.  Two  USB  ports  and 
100  Base-T  Ethernet  are  also  available 

Most  notably,  however,  is  the  capability 
to  wirelessly  transmit  data,  saving  time, 
and  manhours  for  download. 


PC/104+  Backplane 

ffiCQ 
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3.5.9  UDAS  Operating  Software 

Of  most  significance  is  that  the  UDAS  Operating  Software  is  focused  on  giving  the  Air  Force 
total  control  over  and  flexibility  in  the  data  collected  by  UDAS,  both  near  term,  as  well  as  long¬ 
term,  as  new  UDAS  versions  and  upgrades  are  implemented. 

Control  over  data  means  that  new  functionality  and  data  analysis  routines,  even  ad  hoc  data 
analysis  can  be  quickly  and  easily  accomplished  without  overall  changes  to  the  operating 
software. 

UDAS  operates  on  the  Linux  Operating  System  using  Red  Hat  7.3,  a  Linux  Distribution.  Red  Hat 
7.3  is  a  stable,  up-to-date  Linux  distribution,  and  provides  a  starting  point  for  UDAS.  Once 
UDAS  is  configured,  there  is  no  reliance  on  Red  Hat  except  for  discretionary  updates  and 
patches. 

The  primary  application  software  is  an  embedded  version  of  the  PASS  3200  product  by  SBS 
technologies. 

The  UDAS  application  program  consists  of: 

•  The  Device  Layer  code  for  all  supported  devices 

•  The  Embedded  PASS  data  acquisition  system 

•  The  Crash  Survivable  Memory  (CSM)  application 

•  The  Maintainer  Archive  (MA)  application 

•  PASS-3200  configuration  file  generator  and  analysis  package 

The  Device  layer  is  composed  of  a  library  of  Linux  device  drivers  and  Embedded  PASS  device 
objects.  The  drivers  provide  low  level  initialization,  test  and  data  access  device  calls  for  each 
supported  data  acquisition  device. 

The  Embedded  PASS  device  object  provides  a  common  device  interface  to  the  Embedded  PASS 
data  acquisition  system  for  each  driver.  The  individual  device  objects  are  based  on  C++ 
inheritance  classes  with  base  classes  defined  for  each  general  category  of  input  devices  (1553,  A 
to  D,  Discrete).  This  two-level  approach  allows  for  easy  addition  of  new  input  devices. 

Device  drivers  and  device  support  object  code  for  all  supported  devices  will  be  included  in  the 
UDAS  CDAP. 

Embedded  PASS  Data  Acquisition  System  has  been  ported  to  Linux  from  proven  PASS-3200 
data  acquisition  library,  and  provides  two  main  components: 

•  A  continuously  running  monitor  thread  to  extract  binary  data 

o  Monitor  thread  collects  data  on  a  timed  or  interrupt  basis,  based  on  individual 
device 

o  Data  is  made  available  in  a  current  value  table  and  a  FIFO  queue 
o  Current  value  table  is  used  for  data  that  is  monitored  periodically 
o  FIFO  is  used  for  data,  such  as  event  data,  that  needs  to  be  monitored 
continuously 

o  Thread  status  on  power  up,  initializes  all  data  acquisition  devices,  and  checks 
device  status 

o  Device  failures  reported  to  a  UDAS  specific  Syslog  file 
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o  Thread  monitors  all  errors  reported  in  Syslog  file  and  reports  errors  via  system 
status  RT-SA  on  1553  bus 

•  An  Applications  Programming  Interface  (API)  that  allows  using  applications  to  request, 
collect,  and  monitor  extracted  data 

o  Designed  to  allow  multiple  outside  applications  to  request  collection  of  specific 
binary  data  from  the  monitor  thread 
o  Provides  functions  to  read  unique  configuration  files 

o  Provides  functions  to  request  the  collection  of  specific  data  by  the  monitor  thread 
o  Provides  functions  to  retrieve  data  from  the  monitor  thread  FIFO  or  current  value 
table 

o  Provides  functions  to  retrieve  and  apply  conversion  information  for  each  data 
point 


The  UDAS  CDAP 
CSM  Software  module 
is  loaded  at  power-up, 
and  configured  at 
runtime  from  unique 
configuration  files. 

The  configuration  file 
identifies  the  data 
source,  extraction  and 
conversion 

information,  sampling 
specifications  (time, 
flight  state),  event 
specification,  and 
reports  any  CSM 
errors  in  UDAS 
specific  Linux  Syslog. 

The  software  module 
builds  circular  queue 

in  CSM  for  periodic  data  and  builds  array  of  event  data.  All  data  consists  of  a  timestamp, 
converted  data.  Data  display  and  analysis  is  available  post-flight  using  PASS  ground  stations  and 
provided  extraction  utility. 

The  UDAS  Maintainer  Module  is  loaded  at  power-up  and  configured  at  runtime  from  unique 
configuration  files.  The  configuration  files  identify  data  source,  extraction  and  conversion 
information,  sampling  specifications,  and  event  specification.  The  Maintainer  Module  builds  the 
Maintainer  Archive  file  containing  large  circular  queue  of  periodic  data,  array  of  event  data.  This 
data  is  all  time-stamped,  converted  data  and  also  includes  reports  of  any  errors  via  UDAS  Syslog 
file.  The  data  is  available  during  flight  for  download  or  display.  Data  display  and  analysis  is  also 
available  post- flight  using  ground  stations  or  provided  extraction  utility. 


UPAS  Specific  Data 
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3.5.10  UDAS  Enclosure  Design  Concept 


The  UDAS  has  a  flexible  enclosure  design  concept  that  allows  the  enclosure  to  be  easily  adapted 
to  the  aircraft  dimension  and  interface  requirements. 


Extruded  Contiguous  Enclosure 


The  enclosure  design  concept  allows  UDAS  to  match  aircraft  form  factor,  mounting,  and 
cabling  using  multiple  PC/ 104  enclosure  types  that  are  available  on  commercial  market. 

For  the  F-16  UDAS  application,  individual  frames  have  been  selected. 

The  enclosure  fits  in  current  CSFDR  SAU  space  with  current  ATR  mounting,  connectors 
to  mate  with  current  aircraft  cables,  considering  both  connector  type  and  cable  lengths. 

-  EMI  Filtered  pins  in  connectors  (-90dB  at  700  MHz) 

Enclosure  machined  from  6061-T651  plate  aluminum 

-  Eliminates  warping  after  milling 

-  Stainless  steel  guide  bushings  between  frames 
Vertical  cooling  fins  exterior  and  interior 

-  CPU  against  the  top  for  additional  heat  transfer 
EMI  gaskets  of  silver-plated  aluminum  in  florosilicone  binder 

-  High  corrosion  resistance 

-  100  dB  down  at  500  MHz 

-  Meets  all  requirements  of  MIL-G-83528  type  D 
30-PSI  differential  pressure  capability 
PC  card  removable  through  door  in  bottom  of  enclosure 

-  Door  opens  to  right  to  clear  cables 

-  Includes  EMI  gasketing 
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3.5.11  UDAS  Capacity 


The  following  capacity  is  being  designed  into  the  F-16  application  of  UDAS.  Other  applications 
may  require  different  configuration  based  on  aircraft  profde. 


MIL-STD-1553  -  AMUX 

SBS  PASS  PC/104-XT 

•  Single  channel  dual  redundant  1553  for 
AMUX 

•  Two/four  channel  cards  available  for 
additional  multiplex  bus  interfaces 

•  Full  function  -  BC,  RT,  BM 

•  128  Kbytes  dual  port  RAM 

•  Power-up  self  test 

•  BIT-RAM  and  Encoder/Decoder  test 

•  -40C  to  +85C 

•  31  RTs  and  all  subaddresses  supported 


28  VDC  Discrete  -  28 

Parvus  62  Point  Digital  I/O 

•  40  points  of  configurable  I/O 

•  Opto-isolated  to  prevent  feedback 

•  16  additional  logic  level  I/O 

•  -40C  to  +85C 

•  8  address  internal  register 


Transducer  -  LVDT  -  5 

North  Atlantic  PC  104  73LD3 

•  6  channels  LVDT 

•  16-bit  resolution 

•  Transformer  isolated 

•  Individual  excitation  inputs 

•  -40C  to  +80C 

•  Continuous  self-test 
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Transducer  -  Synchronous  -  2 

North  Atlantic  PC  104  73SD3 

•  6  channels  programmable  Synchro 

•  16-bit  resolution 

•  Transformer  isolated 

•  -40C  to  +80C 

•  Continuous  self-test 


Analog-15  /  Discrete  (shunts)-17 

Access  104-AIO12-8  x  2 

•  Analog  I/O 

o  8  channels 

o  Single  ended  or  true  differential 
o  100  KHz  sampling  rate 
o  Programmable  gain  and  range 

•  Digital  I/O 

o  24  parallel  bits 
o  I/O  pulled  up  to 
5V 

•  Event  counter/timer 

•  Frequency  and  pulse 
measurement 

•  100  KHz  sampling  rate 

•  -40C  to  +85C 
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Crash  Survivable  Memory 


The  Crash  Survivable  Memory  device  in  UDAS  is  provided  by  L-3  Communications  Corp,  and  is 
the  latest  of  the  state-of-the-art  for  crash  survivable  memory.  The  unit  is  identical  to  the  unit 
being  developed  for  the  JAS  30  Gripen  fighter. 


L-3  Communications/  Electrodynamics  (L-3/EDI)  manufactures  a  wide  range  of  solid-state  flight 
data  recorders  and  crash  survivable  memory  units  for  tactical  military  aircraft.  They  also  design 
and  manufacture  solid-state  data  storage  systems  for  military  and  aerospace  applications.  The 
company's  expertise  is  in  the  design,  development,  and  production  of  the  data  recorders,  crash 
memory  units,  and  data  storage  systems.  These  systems  have  been  used  on  a  wide  range  of 
platforms  including  B-1B,  F-22,  T-45,  B-2,  F-4,  F-15,  F-16,  C-5  Galaxy,  NATO  AWACS,  and 
the  Space  Shuttle. 

The  unit  being  used  for  UDAS  has  the  following  features: 

•  Based  on  qualified  B-2. 

•  4.5”  wide,  by  3”  high,  by  6”  long  (w/beacon) 
and  weighs  about  6.5  pounds. 

•  Cooled  by  convection  and  radiation. 

•  .5MB  Memory  expandable  to  256MB. 

•  RS  422  data  link.  Can  be  adapted  to  1553, 

Ethernet,  IEEE  1394A/B  or  other  high  speed 
busses. 

Survivability  Features 

•  Hi-Level  Impact  Shock  -  3,400g,  5-8  ms. 

•  Penetration  -  6axes  @  500  lbs.,  10  ft.,  1/4” 
steel  dowel  penetrator  pin. 

•  Static  Crush  -  5,000  lbs.,  5  min.  each  axis. 

•  Fire  Resistance  -  1,000°C  for  30  to  60  minutes ,  slow  burn  for  10  hours. 

•  Sea  Water  Immersion  to  20,000ft.  for  30  days. 
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3.5.12  UDAS  Development  Team 


ENGINEERING  &  ITCHNOLOGY  LI  D 


•  Advanced  Design  Concepts;  Lead  UDAS 
System  Design ,  Open  Architecture 


<© 

communications 


•  Proven  Crash  Survivable  Module 

technology;  Most  advanced  CSM  Module 
available  today;  Selected  for  Gripen ,  JSF 


Technologies,  Inc. 


•  State  of  the  art  data  collection  software 
and  1553  bus  analyzer 


RLWINC. 

EMBEDDEDSOFTWARE 


Industry  leader  in  Wireless  technology  and 
embedded  software  design 


31 


3.6  Application  of  Prognostics  Framework  to  Monitor  Aircraft  Conditions 
&  Trigger  Events 

It  became  clear,  at  the  UDAS  Preliminary  Design  Review  (PDR)  that  the  R-Net  software 
approach  does  not  include  the  extensive  coding  required  to  monitor  aircraft  parameters,  per  the  F- 
16  specification,  and  trigger  snapshot  events.  This  is  a  critical  part  of  the  UDAS  functions. 
However,  the  typical  approach  to  hardcoding  this  functionality  is  indeed  a  huge  effort.  In  order  to 
ensure  the  success  of  the  UDAS  program,  Giordano  Automation  has  recommended  that  R-Net 
look  at  Giordano  Automation’s  object  oriented  modeling  approach  to  this  issue.  The  result  is  a 
white  paper,  below,  on  R-Net ’s  findings. 

As  a  result,  Giordano  Automation’s  Prognostics  Framework  was  used  to  monitor  aircraft 
conditions  and  trigger  events  to  create  special  log  files.  Section  3.6.1  provides  a  description  of 
that  application. 

3.6.1  Use  of  Giordano  Diagnostician  in  UDAS 

Background 

The  UDAS  system  is  divided  into  two  modules,  a  common  module  that  would  be  used  on  all 
aircraft  applications  (Common  Data  Acquisition  Module  -  CD  AM)  and  a  unique  module  that 
provides  interface  for  CD  AM  with  the  host  aircraft  (Aircraft  Interface  Module  -  AIM).  The  AIM 
module  includes  Configuration  Files  that  configure  CD  AM  and  other  software  modules  that 
provide  application  programs  that  to  address  specific  data  handling  requirements  of  the  host 
aircraft. 

One  of  the  attributes  of  UDAS  is  the  capability  to  host  third  party  programs.  This  capability 
includes  functions  that  allow  the  third  party  program  to  access  data  that  has  been  received  by 
UDAS  and  to  store  results  of  data  analysis  in  UDAS  memory  locations.  These  third  party 
programs  can  be  part  of  the  common  (CD AM)  module  or  part  of  the  host  aircraft  interface  (AIM) 
software.  If  the  third  party  program  is  part  of  CD  AM  it  would  normally  be  a  general  use 
algorithm  whose  parameters  would  probably  be  programmed  by  the  AIM. 

If  the  third  party  software  is  part  of  AIM  software  it  would  be  installed  in  the  CD  AM  third  party 
program  area  when  AIM  is  loaded  at  boot-up.  In  this  case  the  program  would  normally  be 
configured  to  fit  the  host  aircraft  needs  during  AIM  development. 

The  UDAS  concept  anticipates,  and  the  UDAS  contract  requires,  that  the  UDAS  software  be  non¬ 
proprietary  and  that  it  can  be  replicated  or  modified  as  needed  by  the  government.  That  is  a 
requirement  for  the  CDAM  common  software  and  this  requirement  is  expected  to  be  maintained 
by  the  USAF  UDAS  program  management.  However,  since  the  UDAS  software  provides  a 
platform  for  third  party  software  and  allow  it  to  be  changed  at  will  by  the  host  aircraft  program 
manager,  it  is  reasonable  that  host  aircraft  management  might  elect  to  use  some  proprietary 
software  if  that  arrangement  was  advantageous.  Use  of  proprietary  software  in  AIM  would  be 
transparent  to  the  UDAS  system  since  the  AIM  software  can  be  changed  as  needed  without 
necessitating  a  change  to  CDAM  software. 


UDAS  F-16  Application 


There  is  an  F-16  requirement  that  UDAS  create  data  records  relating  to  special  events.  The  record 
can  be  a  time  span  of  single  or  multiple  data  streams  or  a  snap  shot  of  multiple  data  streams  at  a 
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specific  time.  The  F-16  UDAS  Subsystem  Specification  and  the  subsequent  F-16  Aircraft  AIM 
Specification  define  the  specific  records  that  are  required  for  the  F-16  platform. 

F-16  data  is  categorized  into  five  data  types: 

Data  Stored  in  the  CSM 

•  Type  1  -  Mishap  data.  This  data  is  stored  in  the  CSM  and  has  the  highest  priority 
for  recording.  Records  that  must  be  stored  in  the  CSM  will  be  handled  by  UDAS 
mishap  data  processing  software.  This  software  cannot  be  changed  without 
coordination  of  multiple  USAF  agencies. 

Data  Stored  in  UDAS  Non-Volatile  Memory 

•  Type  2  -  Individual  aircraft  Tracking  Data  (IAT). 

•  Type  3  -  Loads/Environment  Spectra  Survey  Data  (L/ESS). 

•  Type  4  -  Engine  Usage  Data. 

•  Type  5  -  Avionics  Health  Diagnostic  Data. 

UDAS  is  being  designed  to  maximize  the  data  handling  processes  in  the  CD  AM  and  thereby 
minimize  the  software  needed  in  the  AIM.  SBS  has  recommended,  and  the  Software  Team 
accepted,  the  concept  that  the  CD  AM  software  should  include  a  set  of  programmable  data 
handling  rules  that  can  be  called  by  the  AIM.  The  objective  is  the  AIM  Configuration  Files 
simply  call  a  specific  rule  and  specify  the  parameters  to  implement  the  rule.  For  instance  a  rule 
might  be  to  record  the  value  of  a  certain  data  stream  only  when  the  data  changes  by  some  amount. 
The  configuration  file  would  call  that  applicable  rule  and  specify  the  amount  of  change  that  would 
cause  a  new  data  value  to  be  recorded.  The  rule  would  include  the  parameters  for  creating  event 
records. 

A  configuration  file  might  have  ASCI  values  such  for  such  a  rule  might  be: 

Rule  Value  =  3  (the  rule  for  records) 

Event  =  1 12,  Yes  (data  stream  112,  when  the  discrete  is  yes  create  the  record) 

Data  =  3,6,9,54,  115,  209  (the  data  streams  to  place  in  the  record) 

Time  =  current  time-  300  (the  base  time  is  the  300  ms  prior  to  the  current  time) 

Range  =  -15, +15  (record  the  data  for  the  selected  data  streams  for  the  period  +/-  15 
seconds  from  the  base  time) 

Store  =  xxxxxx  (the  memory  location  to  store  the  record) 

NOTE:  if  the  change  simple  requires  that  the  change  be  recorded  the  record  portion  of  the  rule 
will  have  null  values 

That  generic  data  handling  rules  feature  of  UDAS  would  apply  to  the  F-16  Type  2-5  data 
processing.  However,  to  create  a  complete  set  of  data  handling  rules  we  would  need  to  have 
detailed  knowledge  of  data  handling  rules  for  multiple  aircraft.  Creating  generic  data  handling 
rules  that  are  robust  also  requires  more  time  and  testing  than  available  in  the  UDAS  Advanced 
Development  Model  (ADM)  program.  Due  to  the  limitations  associated  with  an  ADM  program 
we  have  been  planning  to  hard  code  the  rules  for  F-16  in  order  to  have  an  operative  system  to 
demonstrate  the  UDAS  concept.  Incorporation  of  the  Giordano  diagnostics  software 
“Diagnostician”  may  offer  the  opportunity  to  delete  the  need  to  write  hard  code  for  the  F-16 
application  AND  would  provide  a  demonstration  of  the  use  of  third  party  software  for  diagnostics 
and  prognostics  data  analysis. 

In  the  UDAS  Program,  there  has  been  much  discussion  about  data  analysis  capability  in  UDAS, 
but  a  demonstration  would  go  a  long  way  toward  convincing  people  that  UDAS  can  actually 
include  that  capability.  It  should  be  noted  that  the  on-board  data  analysis  function  must  not 
interfere  with  the  basic  data  acquisition  and  mishap  data  handling  functions  otherwise  there  could 
be  lost  of  data  and  delay  of  mishap  data  storage  in  the  CSM  beyond  the  required  time  frame.  For 
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any  data  analysis  or  other  third  party  software  to  be  incorporated,  CD  AM  software  must  include  a 
priority  system  of  interrupts  to  assure  that  data  acquisition  and  the  mishap  data  processing  and 
storage  functions  have  CPU  priority.  Some  delay  of  data  analysis  is  not  a  major  problem  since  the 
results  of  data  analysis  is  not  part  of  a  control  system  and  near  real  time  for  data  analysis  is  good 
enough. 

Use  of  Giordano  Diagnostician 

We  understand  that  the  Giordano  Diagnostician  includes  record  creation  capability  among  the 
Diagnostician  functions.  We  propose  that  Giordano  and  the  UDAS  team  explore  the  use  of 
Diagnostician  as  a  third  party  program  to  fulfill  the  requirement  for  creating  Types  2-5  records  for 
the  F- 16  application.  Other  Diagnostician  capability  should  also  be  considered  and  implemented 
as  feasible.  Using  the  Diagnostician  would  significantly  help  shortened  the  UDAS  schedule  and 
would  demonstrate  how  UDAS  can  use  third  party  programs  within  the  UDAS  in-flight 
diagnostic/prognostic  data  analysis  functionality.  Preliminary  discussions  have  indicated  use  of 
Diagnostician  may  be  feasible. 

R-Net  has  done  a  preliminary  review  of  use  of  Diagnostician.  We  would  like  to  start  a  dialog  with 
Giordano  to  get  a  better  understanding  of  the  program  and  to  determine  if  use  of  Diagnostician  in 
the  ADM  system  is  truly  feasible.  If  it  is,  we  would  then  develop  a  set  of  actions  to  implement 
some  portion  of  Diagnostician  in  the  ADM  system.  There  are  a  number  of  issues  that  we  have 
identified  that  would  have  to  be  resolved,  but  they  do  not  appear  to  be  too  difficult.  One  of  them 
is  that  Diagnostician  would  have  to  be  ported  to  Linux.  I  believe  that  making  Diagnostician  part 
of  the  F- 16  AIM  as  a  designated  AIM  data  analysis  program  is  the  best  way  to  proceed  as 
discussed  above. 

3.6.2  Prognostics  Framework  Application  to  F-16  UDAS  AIM 

The  Prognostics  Framework  is  an  enhancement  of  Giordano  Automation’s  Diagnostician.  The 
Prognostics  Framework  extends  the  Diagnostician  to  predictive  reasoning.  In  run-time,  the 
Prognostic  Framework  reads  operational  data,  test  and  sensor  results  and  provides  a  call-out  of 
existing  faults  or  impending  failure  events.  It  does  this  by  correlating  test  /sensor  results,  under 
expected/de  fined  operating  conditions,  to  a  hierarchical  model  of  the  system.  The  model  can  be 
derived  directly  from  CAD 
data  (EDIF  netlists)  or  by 
building  a  hierarchical  model 
of  the  system  using  the 
development  system.  The 
user  identifies  what  test  and 
sensor  data  will  be  available 
in  run-time,  and  the  coverage 
of  those  tests/sensors  across 
the  design.  Additionally,  the 
user  can  identify  and  define 
detailed  algorithms  and 
mathematical  functions  to  be 
applied  to  the  data,  as  well  as 
filters.  Run-time  reasoning 
is  based  upon  the  coverage 
defined  for  the  tests/sensors. 

Set  covering  algorithms,  pre¬ 
computed  into  the  run-time 

knowledge  base,  are  used  to  increase  monitoring  and  diagnostic  accuracy  and  speed. 


What  Does  the  Prognostics  Framework  DO? 

•  Integrates  Diagnostic  /  Prognostic  Mechanism  Outputs  From  Many 
Subsystems 

•  Provides  Prognostics  Analysis  /  Reasoning 

-  Monitors  Degradation  of  Signals  /  Measurements  over  time 

-  Depletion  of  Consumable  Items 

-  Accumulates  Wear  Factors 

-  Engineering  Correlations 

-  Tracks  PMS  based  on  Wear  /  Use  factors  as  well  as  time 

-  Serial  Number  Tracking  of  high-end  components 

•  Allows  for  integration  of  complex  algorithms  and  functions 

•  Provides  Diagnostic  /  Prognostics  Analyses  /  Reasoning 

•  Let’s  you  look  at  trend  data 

•  Links  to  Tech  manuals,  PMCS,  Supply,  etc.,  based  on  specific  fault  or 
equipment  condition 
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The  Prognostics  Framework  contains  many  features  and  advanced  mathematical  and  function 
processing  that  allows  it  to  look  forward  in  time.  It  can  monitor  the  depletion  of  consumables,  the 
degradation  of  various  parameters  alone  or  in  combination  with  other  parameters.  It  can  also 
monitor,  assess  and  predict  remaining  life  of  various  types  of  system  elements.  Additionally,  the 
Prognostic  Framework  is  capable  of  integrating  other  prognostic  techniques  that  are  highly 
specific  to  various  items  into  the  overall  framework,  such  as  oil  monitoring  systems,  vibration 
analysis  systems,  thermographic/video  imaging,  etc.  Integration  of  prognostic  techniques  into 
the  Prognostics  Framework  is  accomplished  by  defining  the  processed  results  of  those  techniques 
as  one  (or  several)  test/sensor  inputs  to  the  model,  including  fault/symptom  coverage  and  critical 
impact  on  functions.  If  the  prognostic  technique  has  its  own  interface,  that  interface  can  be 
displayed  by  the  Prognostics  Framework  run-time  user  interface  at  any  time.  However,  the 
prognostic  technique  interface  is  usually  only  displayed  by  the  Prognostics  Framework  run-time 
user  interface  when  the  prognostic  technique  indicates  a  symptom  or  an  impending  failure  . 


The  intent  behind  the 
Prognostics  Framework  is 
first,  to  leverage  off  existing 
system  diagnostic,  (test  and 
sensor)  resources  to  achieve 
condition  monitoring  and 
prognostics.  Secondly,  it  is 
to  provide  an  open 
architecture  information 
framework  under  which  any 
equipment-specific 
prognostic  and  trending 
technique  can  be  integrated 
into  an  overall  system-level 
health  management  system. 

The  health  management 
system  includes  information 
on  the  status  of  individual 
systems  and  equipment 
contained  in  a  hierarchical 
representation  of  the  system.  The  health  management  system  also  gives  an  indication  of  the 

ission  across  specific 
timeframes.  It  does  this  based  on 
the  correlation  of  equipment  to 
functions,  and  the  assigning  of 
equipment  faults  to  the  ability  of 
the  equipment  to  perform  the 
function,  and  then  correlating 
functions  to  mission  capability. 
Finally,  the  information 
framework  includes  repair  item 
data  and  repair  action  data  fields 
that  enable  integration  of 
maintenance  /  logistics  data 
directly  within  the  model,  or 


system’s  overall  mission  capability  and  readiness  to  perform  a  i 


ON-BOARD  HEALTH 
MANAGEMENT  SYSTEM 


•  Run-Time  Software  designed  for 
embedded  applications 

•  C  Code  that  can  be  cross-compiled  to  any 
platform 

•  Implementation  Strategy:  Centralized, 
Distributed,  Hierarchical 

•  Software  functions  serve  as  building  blocks 

-  Integrate  building  blocks  to  build 
desired  functionality 

-  Design  User  Interface  as  desired  or  use 
existing 

-  Well-documented  API 


Generic 


API 


Prognostic/Diagnostic  Model-Based 
Reasoning  Algorithms 


How  does  the  Prognostics  Framework  reason? 


1.  Accept  prognostic/diagnostic  software 
outputs,  BIT  and  parametric  data  as 
symptoms 

2.  Apply  model-based  reasoning  Al 
algorithms  to  prognose/diagnose  the 
implication  of  out  of  tolerance  symptoms 
on  each  future  time  point  defined  in  the 
model 

3.  Identify  the  components  and  sub-systems 
affected  by  predicted  failures  -  sub¬ 
system  health 

4.  Identify  the  functions  and  missions 
affected  by  predicted  failures  -  mission 
readiness 

5.  Identify  the  repair  actions  needed  - 
anticipatory  maintenance 


(1)  Symptom  Data 


(3,  4,  5) 


L 


Subsystems 
Parts 
Faults 


Functions 

Missions 


links  to  other  systems,  such  as  supply  data  base  systems  and  interactive  electronic  technical 
manuals. 

The  information  architecture  used  in  the  Prognostics  Framework  is  powerful  and  flexible.  Models 
for  specific  pieces  of  equipment  can  be  combined  into  the  overall  system  hierarchy  and  sensor 
implications  and  interdependencies  across  the  system  level  can  be  defined. 

For  the  UDAS  system  applied  to  the  F- 16  replacement  of  the  F- 16  CRFDR,  the  Prognostics 
Framework  is  used  to  preprocess  and  monitor  all  aircraft  parameters  recorded  by  the  data 
acquisition  system  for  specific  trigger  events.  Upon  triggering  of  an  event,  a  specific  log  file  entry 
is  generated.  The  Prognostic  Framework  is  applied  to  Types  2  (Aircraft  Tracking),  3  (Structural 
Data)  and  4  (Engine  Monitoring)  data. 

F-16  Data  Model 

The  F-16  model  was  set  up  to  identify  trigger  events  rather  than  faults.  A  different  trigger  event 
was  defined  for  each  different  type  of  data  to  be  stored.  The  events  are  used  to  capture  snapshot 
data,  details  around  specific  events,  occurrence  counts  and  time  spent  in  specific  states  as  defined 
in  the  F-16  CSFDR  specification. 

Source  Data  Inputs 

All  data  to  be  input  to  UDAS  was  identified  as  source  data  inputs.  The  definition  of  the  data 
includes: 

1.  Input  data  name 

2.  Description  (English  language  description  plus  reference  paragraph  from 
specification) 

3.  Data  Type  (Boolean  Yes/No  Value,  Floating  Point  Number,  Integer  Value,  or  String) 

4.  Data  Dimension  (e.g.,  Discrete,  Timestamp,  Degrees,  Knots,  etc.) 

5.  Data  Size  (number  of  bits) 

6.  Data  Location 

Data  Processing 

The  processing  of  the  raw  input  data  (source  data  inputs)  to  derive  calculated  parameters  and  for 
the  evaluation  of  the  inputs  were  identified  in  the  Source  Data  Processing  tool.  This  includes: 

1 .  Mathematical  equations  to  be  applied  to  raw  input  data  to  generate  calculated 
parameters 

2.  Functions/algorithms  to  be  applied  to  raw  input  data  to  generate  calculated 
parameters 

3.  Filtering  to  be  applied  to  raw  or  calculated  parameters  (primarily  used  here  for 
definition  of  valid  ranges) 

Prediction  Model 

The  Prediction  Model  was  used  to  correlate  raw  and  derived  (calculated)  parameters  to  criteria 
causing  an  event  to  be  triggered. 
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3.6.2  Simple  Example 

The  following  is  provided  as  a  simple  example  of  the  application  of  the  Prognostics  Framework 
to  the  F- 16  UDAS  to  cause  the  triggering  of  an  event  to  be  logged.  Most  of  the  modeling  is 
actually  much  more  complicated  due  to  the  functions  applied  to  monitor  events,  such  as  the 
analysis  for  Out  of  Slope  and  the  Peak/Valley  search  algorithm. 


Requirement:  Trigger  an  Event  upon  Valid  Weapons  Release 


Event  Name: 

Type3  In-Flight  Snapshots.Valid  Weapons 
Release  State  Change 

Where  [Type3  In-Flight  Snapshots] 
is  the  category,  and 

[Valid  Weapons  Release  State  Change] 
is  the  actual  trigger  event. 

Event  Trigger  Name: 

VLDWPNREL  TRIGGER 


^injxj 

Define  the  mode/  data  out  of  tolerance  fauft  conditions. 

The  Prognostic  Framework  detects,  isolates  and  determines  hard  and  impending  failures  based  on  the  relationship  between  model 
data  inputs  and  faults  over  time.  Use  this  tool  to  define  those  relationships  as  out  of  tolerance  value  ranges. 


View  fcy  mmirl  data  iapmts 


View  by  subsystems,  parts,  faults 


1)  Select  a  model  data  input 
T  3D_VLDWPN  R  E  L_Q  U  T  S I D  E_S  LO  PE  *  I 

T3D_VTSI_0UTSIDE_SL0PE 
T  3D_VX_0  UTSIDE_SLOPE 
T  3D_VY_0  UTSIDE_SLOPE 
T  3D_VZ_0  UTSIDE_SLOPE 
T3D_WINGFIRST_0UTSIDE_SL0PE 
T  3D_YAWACE  L_0  U  T  S I D  E_S  LO  PE 
T4D_CIC 
T4D_FTC 

T  4D_FTIT_0UTSIDE_SL0PE 
T4D_LCF 

T  4D_MACH_0UTSIDE_SL0PE 
T4D_N1_0UTSIDE_SL0PE 
T4D_N2_OUTSIDE_SLOPE 
T  4D_PERI0DIC_SNAPSH0T_REQUES 
T4D_PLA_0UTSIDE_SL0PE 
T4D_PRESALT_0UTSIDE_SL0PE 
T  4D_PYR0TEMP_0UTSIDE_SL0PE 
T4D_TFAT_0UTSIDE_SL0PE 
TOT_WEIGHT_CATEGORY_CHANGE 


(2)  Faults  covered  by  source  data  VLDWPNREL_TRIGGER' 


Assign  new  fault  coverage  |  Remove  fault  coverage  | 

(3)  Define  the  model  data  out  of  tolerance  ranges  that  will  identify  the  fault  over 
time.  If  the  model  data  input  falls  inside  the  range  including  the  end  values,  the 
fault  is  suspect.  If  only  a  low  value  is  defined,  the  fault  is  suspect  when  the  model 
data  input  is  >=  to  low  value.  If  only  a  high  value  is  defined,  the  fault  is  suspect 
when  the  model  data  value  is  <=  the  high  value. 


Prediction  Information 


Prediction  T  ime  |  Fault  I  f  Value  I  s  Above  |  Fault  I  f  Value  I  s  B  elow 


Symptom  Is  Required  ▼  | _ Plot  graph _ |  Save  value  r< 


Prediction  Source  Data  T ool 


Prediction  Time  Tool 


Related  Source  Data: 

Name:  VLDWPNREL 
Description:  Valid  Weapon  Release 
Type:  Boolean 
Dimension:  Logic  State 
Size:  1 

Name:  VLDWPNRELTIME 
Description:  Valid  Weapon  Release 
-  time  reference 
Type:  Floating  Point  Number 
Dimension:  Time  Expression 
Size:  64 


37 


Processed  (Derived)  Data 


Working  Data  Name 

Equation  or  Function 

Model  Data  Name 

PREV  VLDWPNREL 

wfVLDWPNREL] 

VLDWPNREL  STATE  CHANGE 

s  [VLDWPNREL]  - w  [PRE V  VLDWPNREL] 

VLDWPNREL  TRIGGER 

f[VALUE  SELECT] (w[ VLDWPNREL  STATE  CHANGE],=[1],=[0]) 

VLDWPNREL  TRIGGER 

Filter:  None 


Prediction  Source  Data  Processing  Tool 


-!□!  x| 


Describe  the  Processing  and  Filtering  of  Source  Data  For  Use  in  Prognostics  Analysis 

In  step  1 ..  apply  mathematical  expressions  to  ready  the  data  in  a  set  order  for  use  in  runtime  Prognostics;  in  step  2  select 
which  data  is  to  be  used  during  runtime  and  what  filtering  is  to  be  applied  to  that  data;  and  in  step  3,  identify  the  source 
of  the  confidence  values  of  the  data. 


1.  Mathematical  Processing 


2.  Data  Selection  and  Filtering 


3.  Data  Confidence  Selection 


Working  Data  Source  Information 

Working  Data  Name 

Source  For  Working  Data  (Select  to  Change) 

MLGWOW TRIGGER 

Math  Expression 

VLDWPNREL 

VLDWPNREL 

VLDWPNREL  TIME 

VLDWPNREL TIME 

VLD  WPN  R  E  L S  T  AT  E CH  AN  G  E 

Math  Expression 

► 

VLD  WPN  R  E  L T  R 1  G  G  E  R| 

Math  Expression 

— 1 

T3D  ALT  HP  OUTSIDE  SLOPE 

Math  Expression 

T  3D M 0  U  T  S 1 D  E S  LO  PE 

Math  Expression 

nn  caq  m  ucinr  qi  npn 

_ L 

Add  Working  Data  Item  1  Edit  Math  Functions  1  Edit  Math  Expression  j 

Delete  Working  Data  Item 

Move  Selected  Row  To  A  New  Location  |  Place  Before  Selected  Row  | 

F 

lace  After  Selected  Row 

Mathematical  Processing  Expression  For  Selected  Working  Data  Item 


f[VALUE_S  ELECT  ]( w[VLD  WPN  R  E  L_S  T  AT  E  _CH  AN  G  E  ]  =[1  ]  =[0]) 


Find  Item 


Trend  Info... 


Done 


Since  the  Prognostics  Framework  generates  numerous  reports,  the  resulting  modeling  details  and 
algorithms  are  self-documenting. 

A  configuration  file  is  used  to  define  the  requirements  for  the  creation  of  specific  log  files  to  be 
created.  Additional  log  files,  or  modifications  to  existing  log  files  can  be  accomplished  by  adding 
entries  in  the  configuration  file. 
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Log  File  Viewer 


A  viewer  was  created  to  support  the  integration  and  test  process.  The  viewer  enables  the  user  to 
select  a  log  file  created  from  a  flight  operation  or  test  run,  and  view  its  contents.  The  viewer  is 
shown  below. 


The  following  figure  is  an  example  of  a  view  for  a  Log  File  created  for  Type  4  data,  Engine  Hot 
Section  Times,  where  the  time  that  the  engine  is  at  various  temperature  ranges  is  accumulated  and 
presented. 


-O  Viewer  For  UDAS  Types  2,  3,  &  4  Log  Data 


Select 

Configuration 

File 


|  C:  \My  D  ocuments\D  ata\T y pe 4 D  ata.  cf g 


40.2.2  GE129  Hot  Section  Times 
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